File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Java in General and the fly likes Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Java in General
Bookmark ""Enterprise" applications and Object-Orientation" Watch ""Enterprise" applications and Object-Orientation" New topic
Author

"Enterprise" applications and Object-Orientation

Tim West
Ranch Hand

Joined: Mar 15, 2004
Posts: 539
Hi all,

This is a question that's bugged me for a while. I'm almost certain there are articles out there on it, but the obvious search terms (like J2EE, object oriented, design) yield zillions of unrelated sites.

My question, basically: does the common design of 'enterprise' (particularly, J2EE) applications hinder use of OO design?

Let me explain: I have a few small J2EE applications that pull data from a database, send it across a Web service, and present it as a set of JSPs (using Struts). I find that in this setting, the most common recommendations involve use of Transport Objects (TOs), which contain data, and "session beans" or "delegates" which contain business logic.

In one sense, this is convenient: The TOs map naturally to form objects in Struts, to XML serialisation classes for my Web service, and to the DAO constructs (EJB etc) for persistence.

However, it also seems anti-OO: my business logic is in one place (session beans, delegates), and the data is in another (TOs). I'm not comfortable with this. To an extent, it seems to be required by the libraries and toolkits I'm using. However, some other factors could impact it:

  • Am I doing poor OO design?
  • Is it caused by the triviality of my applications - because they are only examples, they contain only a small amount of business logic. However, they have all the mess of persistence, the web tier, and Web services. Would it be that in a more realistic application, with more business logic, it would be possible to do a better OO design? (That said, the larger app I worked on has the same traits as my ones now).
  • Is this an issue at all?


  • As I say, I'm sure there must be blog entries / literature on this, I just can't find it. Any thoughts?


    -Tim

    (BTW, I posted this in the Intermediate forum because it seems the right place to discuss general "OO" ideas. I also thought about the Design Patterns and J2EE forums...I wasn't sure. Mods - move it if you think it's worthwhile =)
    [ August 02, 2005: Message edited by: Tim West ]
    Jeanne Boyarsky
    internet detective
    Marshal

    Joined: May 26, 2003
    Posts: 30299
        
    150

    Tim,
    I forget where I read this, but someone brought up the point that Enterprise apps should think about OO at the component level rather than the class level. For example, you provide an API to a back end component.

    Of course there are micro examples of OO in portions of an Enterprise app too.


    [Blog] [JavaRanch FAQ] [How To Ask Questions The Smart Way] [Book Promos]
    Blogging on Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, OCAJP, OCPJP beta, TOGAF part 1 and part 2
    Stan James
    (instanceof Sidekick)
    Ranch Hand

    Joined: Jan 29, 2003
    Posts: 8791
    Interesting, I probably would have turned that around. Do the best quality OO design you can within a component, but stateless services and component interfaces are not very object-like. When you get into web services and SOA the APIs are not objects at all and the services we call could be implemented in COBOL for all we care. I see things like DTOs as serious compromises to OO goodness; they are necessary in some architectures, but that doesn't make me like them any better.


    A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
    Tim West
    Ranch Hand

    Joined: Mar 15, 2004
    Posts: 539
    Thanks for writing guys!

    Jeanne,

    That's an interesting thought...It is easy to get stuck in the minutiae of individual objects. In my particular applications, I can't find an OO paradigm on any level - but this could be caused (in part, at least) by a non-OO design. AFAIK, the apps are structured in an "out of the book" fashion, though (though I'm not saying this is an inherently good thing).

    Stan,

    What you've described is basically what I'm seeing - the various interfaces force a procedural paradigm, to an extent. I've been unable to push "real" business methods into the objects that relate to them. For example, I can't say customer.purchase(stuff) because purchasing logic immediately talks to both a Web service and a database, and pushing those sort of concerns into each DTO (well, what is currently a DTO) seemed even uglier.

    The methods I can push into the DTOs are limited to those that calculate information about that DTO - glorified getters, e.g., if a class stores a persons date of birth, a typical (though trivial) example would be getAge().

    Not sure I've added much here, but thanks again for the thoughts.


    -Tim
    Ilja Preuss
    author
    Sheriff

    Joined: Jul 11, 2001
    Posts: 14112
    Martin Fowler has an interesting article about this phenomenon: http://martinfowler.com/bliki/AnemicDomainModel.html

    And another one on DTOs: http://martinfowler.com/bliki/LocalDTO.html

    I've also heard people say that EJB's make it much harder to come up with a good OO model. And I've heard some say that it becomes easier with EJB 3. Fortunately, I won't have to find out in the foreseeable future...


    The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
    Ilja Preuss
    author
    Sheriff

    Joined: Jul 11, 2001
    Posts: 14112
    BTW, you can definitely write "Enterprise" applications without using this EJB stuff. There even is a book out there called "J2EE without EJB" or something...
    Stan James
    (instanceof Sidekick)
    Ranch Hand

    Joined: Jan 29, 2003
    Posts: 8791
    There are days I'd just rather write it in mainframe COBOL. It would probably be an order of magnitude faster, too.

    Is that apps-without-EJB book subtitled Revenge of the POJO or Return of the POJO or Power to the POJO or something cute like that? My project runs in an EJB container but it has one "gateway" SLSB and the rest is pretty much POJOs. We rely on CMT and container data sources under the covers somewhere.
    Joe Ess
    Bartender

    Joined: Oct 29, 2001
    Posts: 8866
        
        8

    Originally posted by Ilja Preuss:
    BTW, you can definitely write "Enterprise" applications without using this EJB stuff. There even is a book out there called "J2EE without EJB" or something...


    Sounds like
    Better, Faster, Lighter Java.


    "blabbing like a narcissistic fool with a superiority complex" ~ N.A.
    [How To Ask Questions On JavaRanch]
     
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: "Enterprise" applications and Object-Orientation