How many models do you have in your application?
In a lot application the answer is -3, one for each layer (presentation, business, dal)
In this case each lays need to maintain constraint, adapters, query translation and maintain.
Today, In the POJO revolution when we each layer can handle POJO and don't need a specific class types any more (no need in extends stateless bean, special dal classes ....) we can build a one single POJO model and bypass it between the layers. We don't need any more to maintain constraints, adapters... in each layer.
But still a lot of application want to hide the hibernate model by additional model above it.
By mistake they call it DTO's but the definition is not correct.
The DTO pattern is a pattern that uses in order to solve a case when we need to combine data from some entities. In this case instead of return all entities we use the DTO pattern and created some kind of view (we might also create a view in the underline) on these entities . this view is DTO.
The dto pattern should be avoided as much as possible and I will explain why in another post, but it's still relevant and in some cases it should use in order to avoid loading a lot of entities or to avoid from expose the collection process to the client of this API.
ORM give you the abstraction on the DB layer you shouldn't add another layer to abstract the DB.
ORM can give you all the solution you need in order to solve the DB - Object oriented mismatch and gap between the persistence to the Model.
Adding new layer in the application is height costing for maintains adapters...
You have difficulty to implementing searching, sorting and etc on any object which is not a real model entity.
Exposing direct the model simpler these features.
As I explained above a lot used the term DTO to describe model layer above the ORM layer so in a lot of articles the term DTOs are evil is used in order to describe the general idea of using in additional layer above the entities and not as a specific case solution.
Ask Google for the term - "DTOs are evil" will return a lot of results.
Let's try to explore some of them and some more resources.
In the top of the Google result for "DTOs are evil" we will find adam-bien site with good explanation about the evil in dto:
DTOs aren't dead. The opposite is true. In certain situations, they become the necessary tool or workaround to solve a particular problem….
It is perfect valid to introduce a dedicated DTO to adapt an incompatible domain layer. It is much better, than changing the domain layer to the needs of a particular client …
On the other hand considering a dedicated DTO layer as an investment, rarely pays off and often lead to over-engineered and bloated architectures. At the beginning the DTOs will be identical to your domain layer - without any impedance mismatch. If you are "lucky", you will get few differences over the time. Especially with lightweight platforms like Java EE 6, the introduction of a DTO is a bottom-up, rather than top-down approach. Exactly like it is the case with DAOs.
(For more see - http://www.adam-bien.com/roller/abien/entry/how_evil_are_actually_data )
Another good reference is Rob Harrop's and Jan Machacek's Pro Spring (Chapter 11):
"Honestly, we cannot think of a reason you would want to do this; in our eyes, it seems that this practice has sprung up out of confusion on how certain J2EE patterns should be used."
You will find another interesting discussion for this issue in the following forum – (http://forum.springsource.org/archive/index.php/t-27716.html )
Some good points there:
"In addition, Christian Bauer and Gavin King explore the issue in Chapter 8 of their Hibernate in Action (http://www.amazon.com/gp/product/193239415X/sr=1-1/qid=1155735659/ref=pd_bbs_1/103-9127259-7133451?ie=UTF8&s=books). They note that the data transfer pattern was invented because fine-grained remote access to entity beans was too slow and entity beans were not serializable."
"In the sample applications I have seen, it looks like people have avoided creating data transfer objects. You didn't really give any application-specific reasons for wanting to use data transfer objects, so I would default to using the domain objects directly and saving yourself from the code duplication and all the work to convert to and from the domain objects."
"If the domain model changed, then it is highly likely that the web tier would have to change anyway.
I think there *are* good reasons and situations in which that loose coupling is beneficial, but they are the exception, rather than the rule. After all, the purpose of most web apps is to interrogate the middle tier; they *are* coupled by definition.
If you need to introduce an adapter between the web tier and the middle tier, then you can always do that as and when you need it, but until then just use the POJOs in the domain model."
And if you have some time visit here:
https://forum.hibernate.org/viewtopic.php?f=1&t=928244&sid=c6565b58c62b0eeee2980b7c2b61ee59&start=30
A good summary of the cons and pros can be found
http://blog.xebia.com/2009/05/11/jpa-implementation-patterns-service-facades-and-data-transfers-objects/
Pros and cons of DTO's
Of course it would be silly to say you should always use DTO's in your architecture. As always it depends. To allow you to make up your own mind, I will list a number of pros and cons of using DTO's:
- Con: DTO's cause code duplication. This is especially the case when your DTO's have exactly the same fields as your domain objects, and even more so when they both have getters and setters for those fields. But having DTO's in your architecture allows you to get rid of the getters and setters in your domain objects.
- Con: DTO's require you to write boilerplate code to copy properties back and forth. Some people have suggested using a Java Bean mapper framework such as Dozer, Apache Commons BeanUtils, or the Spring Framework's BeanUtils class, but that requires you add getters and setters to your beans and we just decided we did not want to do that anymore!
- Pro/Con: DTO's make it impossible to use EntityManger.merge to copy their state to your persistent objects. Instead you'll have to apply the DIY merge pattern as described in my blog on saving (detached) entities. Of course forcing you to do something a particular way, and one that is not 100% satisfying, is not really an advantage. But at least the DTO and the DIY merge work well together.
- Pro: DTO's ensure you are not hit by unexpected lazy loading problems in your presentation layer. Or in the case of remote invocations they protect you from lazy loading problems when serializing for transport or, even stranger, on the client.
- Pro: The DTO pattern forces you to think about the interface of your application. You can make your DTO's richer than your plain domain objects, e.g. by adding security information to them. Or you can group information from multiple domain objects into one DTO to make the interface easier to use.
