• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

EJB 2.0 and DTOs?

 
Joe Boxer
Greenhorn
Posts: 15
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 8927
Firefox Browser Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
David Harkness
Ranch Hand
Posts: 1646
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 234
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
David Harkness
Ranch Hand
Posts: 1646
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic