Win a copy of Learn Spring Security (video course) this week in the Spring forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

"Enterprise" applications and Object-Orientation

 
Tim West
Ranch Hand
Posts: 539
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
    author & internet detective
    Marshal
    Posts: 34071
    331
    Eclipse IDE Java VI Editor
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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.
     
    Stan James
    (instanceof Sidekick)
    Ranch Hand
    Posts: 8791
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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.
     
    Tim West
    Ranch Hand
    Posts: 539
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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
    Posts: 14112
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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...
     
    Ilja Preuss
    author
    Sheriff
    Posts: 14112
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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
    Posts: 8791
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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
    Posts: 9256
    9
    Linux Mac OS X Windows
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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.
     
    • Post Reply
    • Bookmark Topic Watch Topic
    • New Topic