The Joel on Software Discussion Group

I have been working with J2EE enterprise application for the past 3 years and it's always the case that we're using entity > DTO, DTO > entity, and mapping files to map to database tables. I consider myself who is still trying to fathom the intricacies of J2EE architecture. I know that this becomes quite a bit of work for a change that is small, and for larger development it can be quite confusing and frustrating when you run into problems.

Recently, I have read books on EJB3 and some online articles that talk about how this approach is not productive and makes the application unnecessary complex. Mostly, they are talking about mapping entity directly to the front-end and no need of DTO to carry data for you.

What I want to know, how can you go with only the entity approach for enterprise type application. Especially, when you have multiple methods in your mapping files for full, partial, or any weird scenario that you may have for keeping the objects as light as possible.

Thanks.

To me it sounds like you want to go a "Databinding" route that is common in .NET.

I gotta say that I kinda like the DTOs (Value Objects).

Well, I am just curious to know the different approaches I am reading in books and their actual implementation in the real world enterprise type application.

In my case, we have a very customizable enterprise application that different clients use, and the application acts based on that particular clients preferences and settings via data loads. I don't see how the straight entity all the way to the front-end will serve the purpose of handling object loading. Client A needs a bag of potatoes, Client B needs apples and so on...

I simply want to come to grip with the how things are done in the real world development-wise and not what I read in the books on simplification approaches, which is to me, in a way, not so true and useful. It's just a theory that you might be able to use 10 percent of a time.

I still think we need DTO's .
In the Java world where I live and code you needed these in order to work with EJB 2.0 (now obsolete in new development) so once you get to EJB 3.0 you might remove the DTO's .
Still I find that what I need to display in the web layer is not the same as what I need to  bring from the business layer. So another object just for presentation can be used.
When you have distributed applications you need to  play with the object but you can't do lazy loading (in Hibernate through bytecode engineering) in another machine (where the web layer is deployed) so a good practice is to use a DTO (a bit dummy but useful).

When you compile with distributed objects (ie ejb 3 entities aka hibernate annotated classes) both the server (jboss for example) and the client (whatever does a jndi lookup to the server to request services/objects)  require all the classes be present.  So, the client has the class files and the server has the class files.  Meaning, if your entity is more than a DTO and has non getter/setter methods, it doesn't matter.  The implementation just sends the 'state' of the distributed object over the wire.

DTO are still useful though; do you want to send an entire, heavy weight order object to the client just to display a table of order search results?

But yeah, EJB 3 is the shiznit.  It's really a monumental shift away from previous versions.

Don't throw them out because they're annoying.  Throw them out because they don't meet the needs of your application.

But.. if your app is:
1. Highly distributed
2. Subject to frequent change (versioning challenges)
3. Has clients written in different technologies
4. Is line-of-business

then I would certainly keep them, as they help in all of those situations.

Perhaps you can investigate a way to generate them?