to DTO or not to DTO?

[holtak]

i`m now in the role of making design decitions for a new application based on ejb3 and jboss

i searched the web for some hints and tipps and found this blog
http://www.jroller.com/page/raghukodali/20050321

the author claims, DTO`s are no more needed, in ejb3.

well, if I read http://java.sun.com/blueprints/corej2eepatterns/Patterns/TransferObject.html
, can`t agree with the authors opinion

another problem in not-using-DTO`s is lazy loading. the session has to be alive to lazyload data. as the session is bound to transaction, one can start a large transaction in the client-app-logic to make lazyloading work. but this actually isn`t very clean design because the client has to know that access to the entity getters has to be encapsulated in UserTransaction. Here comes the session-per-view pattern in mind. But thats ok for spring and other lightweights.

but, the truth is, that if one requires speed (and I do), the DTO`s are real pain in the butt, because of the additional reflection mapping (BeanUtils and co.). here is the Entity-to-viewTier approch much more effective.

so now i`ve got a bunch of questions:

1. whats the best way to keep the session open to be able to lazyload on demand in the application-logic(view tier), when using entity-beans to transfer dato to the application/view tier (actually an action class for struts)

2. (or) how to speed up DTO mapping (caching?)

3. what is your opinion on this all people?

see u online

[bill.burke]

The opinion is that if you need to load lazily loaded data, then either traverse the relationship before you send the entity (detached) to the application view tier or...

Explicilty fetch the lazy loaded relationship when you query.

from Item i left join fetch i.bids

[epbernard]

The opinion is that if you need to load lazily loaded data, then either traverse the relationship before you send the entity (detached) to the application view tier or...

I agree, to did the exact same thing when you used the DTO pattern actually

[holtak]

"epbernard" wrote:

The opinion is that if you need to load lazily loaded data, then either traverse the relationship before you send the entity (detached) to the application view tier or...

I agree, to did the exact same thing when you used the DTO pattern actually

yes, its actually the same with one difference:
most of our entity beans have collections of beans which have again collections of beans... - sometimes more than 5-6 levels

but the client almost never requires "all" levels, but _may_ require all, because he`s allowed to. If I do the prefetch thing, I must preload all or have many many query-methods which actually prefetch to some level to not risk a lazy-loading-exception. The client programmers must be very kind and never ever call the wrong method.

The antipattern is, that we actually don`t know what data (how deep dig in), the client needs. So to fullfill client needs, we have to know and design and develop for him and with him. The bussiness interface is reduced to method calls and there are actually no "business data object" domains, just "entity domains" which have not much common with the business-view presentation of the problem, because they present the persistence representation of the data. We may start with DTO`s which almost one-to-one map the entity beans, but as the project develops and new features, requirements and iterations pass, the DTO`s start to differ more and more. The problem is, more lines of code, more complex programming, slowdown. When comparing the +- of the solutions I choose DTOs and leave me the backdoor of doing prefetch and exploiting entity beans to the client where performance gets critical.

see you online

[lipido]

Other way to do something, but It doesn't have only advantages is (I have not implemented it yet, because I'm new in EJB3):

When I create an Entity do two things:

1) Create a interface (say IOrder) with all the methods that a client "can" satefy call (say getDate, getDescription, --plain properties--).

2) Create the Entity POJO (Order implements IOrder) implementing this interface.

The Session Bean can have the method:

Collection getOrders()

Problems:
- The client need other methods in the session to get the lineItems, say:
Collection getLineItems(IOrder)

The session bean becomes more and more complex.

What do you think?

[lipido]

I have got problems with HTML!

"lipido" wrote:


Collection getOrders()

....

Collection getLineItems(IOrder)

The correct is

Collection<IOrder> getOrders()

....

Collection<ILineItems> getLineItems(IOrder)

[redijedi]

IMHO, it really depends. The bottom line is that you can't have it both ways. You cannot have all your data available to the client by making one small (in terms of graph size) method call and not return too much data in one shot. That just doesn't make sense. This is where use cases and usability testing come into play. Sometimes, you can get away with a drill-down UI approach that is complimentary to a lazy-load implementation. Other times you will need large datasets in a reporting situation (for example). You really can't have it both ways. If you believe it when people claim to do so, I've got a bridge you might also be interested in.

At the end of the day, DTO is a pattern. Good, bad, who cares? Does it do what you need it to do? Does it have a negative or positive impact on your project? Will the overhead of maintaining another object outweigh handling the issues related to eager/lazy loading? No one here can answer this for you.

Personally, I use entities as my DTOs, but only for OLTP work. What I've found to make my applications highly scalable is to split the OLTP processing from the OLAP along the lines of ejb and jdbc. I've found that EJB is very good for discrete, distributed, transactional operations that span multiple services, but not so hot for reporting functionality. Conversely, JDBC is highly efficient when accessing data. Resultsets are the most efficient way to work with data sets (go figure). Yet, the boiler plate code for this type of thing sucks. Depending on the result size, you could use an ORM for this too. The important thing to remember is that you need to identify where data is being used and how. This should be done before building your app anyway. Armed with this knowledge, you will not be so tempted to let EJB try to be everything to everyone.

Entities are being misused because marketing geniuses know that people want to solve the problems outlined above with a silver bullet. "No DTOs ever again!" Since I have found this to be false, entities seemed to be way overhyped. They are not. You must use them for what they are good for. Odds are low that you will need a distributed, transactional read for analytics...so don't use entities for this use case.

Besides, every join, be it in SQL or Objects, is a performance hit. I suggest taking it one step further and using warehousing techniques to ensure the most efficient possible use of your db with regards to OLAP. Use EJBs to manage the OLTP and fire asynch messages to update your warehouse (which can be as simple as a set of denormalized tables). Provided that your asynchs are durable, you will have produced a very scalable, reliable solution.

...Just my opinion.
T