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?
(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 ]
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.
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
Joined: Mar 15, 2004
Thanks for writing guys!
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).
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.
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
Joined: Jul 11, 2001
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...
Joined: Jan 29, 2003
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.