aspose file tools*
The moose likes EJB and other Java EE Technologies and the fly likes EJB 2.0 and DTOs? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "EJB 2.0 and DTOs?" Watch "EJB 2.0 and DTOs?" New topic
Author

EJB 2.0 and DTOs?

Joe Boxer
Greenhorn

Joined: Oct 23, 2003
Posts: 15
Hi,
A quick one. What is the best practice on the following scenario:
we have a client, a session fa�ade and an entity EJB lets say Abc. The client passes a AbcDTO to the session fa�ade, now knowing that co-located EJBs (here the session and the Abc Entity) use local interfaces, the DTO is not a big help in therms of performance. But is it not better to still pass the DTO further to the entity bean instead of invoking a number of set methods? Would it not increase the readability and keep the number of methods in the interface of the entity bean minimal?
Any pros and cons on that?
Cheers
Joe
Pradeep bhatt
Ranch Hand

Joined: Feb 27, 2002
Posts: 8919

I would have my enity bean expose set/get method for each attribute as well a set/get method for DTO. This makes my bean flexible.


Groovy
David Harkness
Ranch Hand

Joined: Aug 07, 2003
Posts: 1646
Originally posted by Joe Boxer:
But is it not better to still pass the DTO further to the entity bean instead of invoking a number of set methods? Would it not increase the readability and keep the number of methods in the interface of the entity bean minimal?

There are tradeoffs to this approach, but it's what I'm using. Each entity bean exposes the getters but not the setters. Instead, there is a method (updateFieldsFromDTO) that takes the DTO and calls the setters directly, bypassing the transaction, security, and other container checks. This does increase performance (how much I do not know), but the cost is that the entity bean needs to know the structure of the DTO.
In some cases you may want to have multiple DTOs per bean (a light version, a full version, etc). You would do this usually to support different presentation layers. Well, now you've put presentation logic in your persistence layer. Not a really big deal, but it may bite you later. So far I've been happy with my approach.
Bill Dudney
Author
Ranch Hand

Joined: Sep 05, 2003
Posts: 234
Hi All,
In thread there is another discussion of this topic.
My basic take is that if you are using XDoclet to generate and consume the DTO's then it is OK (not great but ok) to have multiple dto's eminating from a single entity. But as you say, you have put presentation layer stuff into your entities. Concretely that will lead to maintenance headaches in the model layer.
Hope this helps.


TTFN,<br /> <br />-bd-<br /> <br /><a href="http://www.amazon.com/exec/obidos/ASIN/0471449156/qid=1064343733/sr=2-1/ref=sr_2_1/002-8375300-3666449" target="_blank" rel="nofollow">Jakarta Pitfalls</a> | <a href="http://www.amazon.com/exec/obidos/tg/detail/-/0471146153/qid=1064343733/sr=1-2/ref=sr_1_2/002-8375300-3666449?v=glance&s=books" target="_blank" rel="nofollow">J2EE AntiPatterns</a> | <a href="http://www.amazon.com/exec/obidos/tg/detail/-/0471462071/qid=1064343733/sr=1-3/ref=sr_1_3/002-8375300-3666449?v=glance&s=books" target="_blank" rel="nofollow">Mastering JavaServer Faces</a> | <a href="http://bill.dudney.net/roller/page/bill" target="_blank" rel="nofollow">Blog</a> | <a href="http://www.jroller.com/page/BillDudney" target="_blank" rel="nofollow">Eclipse Blog</a> | <a href="http://www.sourcebeat.com/TitleAction.do?id=2" target="_blank" rel="nofollow">Eclipse 3 Live</a>
David Harkness
Ranch Hand

Joined: Aug 07, 2003
Posts: 1646
Originally posted by Bill Dudney:
But as you say, you have put presentation layer stuff into your entities. Concretely that will lead to maintenance headaches in the model layer.

As I came from the client-server world of 1989-95, and we tend to use what we know, I created a DTO class that is modeled after a database row. Given that we're mapping our entity beans directly to the database tables and that I don't want the EJB layer producing objects taylored to the presentation layer, this works pretty well. [Side note: I still feel that entity beans are overkill used this way, but it wasn't my choice.]
DTO has a state (normal [came from DB], new, deleted, and limbo [created then deleted without being saved]), a dirty flag and a Map of field entries. Each field entry has a value and a dirty flag.
DTOTree extends this to maintain a list of DTO lists, meaning it can have multiple sets of "owned" or "related" objects. For example, the UserDTO has a list of AddressDTOs and PhoneDTOs. The session data layer produces and consumes DTOTrees, passing them to the various entity beans as needed. Since they aren't presentation-specific, each bean has only one DTO. As our objects are all small, this is fairly reasonable.
The upside is that the whole data layer is fairly simple and readily factorable into a good framework that requires little to create new domain objects. The downside is that, again, I feel this is over-engineered. The applications I'm building now aren't any more complex than the PowerBuilder apps I wrote before. Same number of tables; same (lack of) complexity in structure; same amount of business logic. Yet we've got so many classes to map a simple POJO to a row in the database.
Anyway, that's what I'm doing, and at least it is working well and is easy to maintain. I still have some refactoring to do in the session-entity coupling that could save me quite a bit of code-writing by creating XDoclet templates. However, is this generally what others using entity beans have found? I do intend to check out Hibernate, but I fear it will be an uphill battle with management, though they keep saying that if we find something better they'll jump at it.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: EJB 2.0 and DTOs?