DTO or domain model object at view level?

Question

I know this is probably a centuries old question, but what is the best practice? Using a domain model object at all levels of your application and even binding values ​​directly to them in JSP (I use JSF). Or convert a domain model object to a DTO at the DAO or Service level and send a lightweight DTO to the presentation level.

I was told that it makes no sense to use DTO, because changes to the database will lead to changes to all of your DTOs, whereas using model objects everywhere will require changes to the affected model object. However, the ease of use and the lightweight nature of the DTO seem to outweigh this.

I should note that my application uses Hibernate Model Objects and uses its own user-created model objects (which is not associated with any database session, it is always separated). Is any of the above scenarios more useful for a rigorous model object model? Using Hibernate has been a huge PITA for things like Lazy Initialization Exceptions.

I am editing this question in the hope of continuing the discussion (not sure if I am doing it right):

The problem with model objects is that they are not flexible at all. The comment below says that the application should be designed so that model objects can be used at all levels. What for? If the user wants a piece of ridiculous functionality, I must tell them: "Well, that will not work with model objects"?

Normal and simple, there is only one time when the model objects will not work. You may have:

public class Teacher { List<Student> students; [tons of other Teacher-related fields] } public class Student { double gpa; [tons of other Student-related fields] } 

but maybe you don’t need all this information. You just need the name of the teacher, the number of students they are teaching this year, and the average GPA for all students. What would you do in this case? Get complete information about teachers and student relationships, and then your code gets an account in the student list and then calculates the total average of all gp inside? This looks like waaaay more effort than just creating a DTO with "String lastName", "int numStudents" and "double combinationGpa;

It may seem that my mind was composed on them, but I still have to work in an application where model objects can be fully used in each case. Regular real-world applications with non-standard user queries simply do not work.

Answer 1

It really depends on the complexity of your application. Mixing domain objects into the presentation layer has two possible values:

• You will be tempted to change your domain object so that it matches you in the presentation layer.
• The level of your presentation will contain additional complexity caused by the mismatch between what your domain objects offer and what you really need. You may not be able to get around this difficulty, but it probably does not apply to the View layer.

If your domain objects are simple and your views are few, skipping the DTO is probably the easiest.

On the other hand, if your domain model can evolve and become complex, and if your views are likely to be numerous and varied, then viewing certain objects may be a good idea. In the MVC world, using ViewModels is common and makes a lot of sense to me.

Answer 2

Another vote for domain objects. Regarding Driven Driven Design management, the domain model is king and should be used wherever possible. The application should be designed so that most layers (infrastructure infrastructure layer) can use domain objects.

I think DTOs are only useful where objects should be serialized. If there is no transmission by wire or into an incompatible architecture, I would not use them. The DTO sample is useful for maintaining serialization outside a domain object. Given that interacting with a UI / Domain does not require serialization, simplicity and use of real objects.

Answer 3

I think that DTO is usually not an anti-pattern. There are many people and systems using them, and the advantage you get is the decoupled layer, which can be designed and modulated regardless of the domain model. Although I agree that you should use domain objects where possible, there are scenarios in which you may encounter problems when linking the view level directly to the domain model.

I did a great job with a view model that only wraps domain objects and delegates most of the operations to them. This delimits the presentation and domain level, allows you to flexibly configure the domain objects, and still does not work much for implementation since the IDEs support the delegation pattern.

Answer 4

Scenarios when a domain object poses a problem:

• you may need aggregated information or other types of “computed fields” sent to the user interface level (in the Flex / GWT example) and don’t want to spoil the domain object
• you may have to serialize a circular graph of objects (in your example, if Student had a List relation), some protocols have problems with this
• Hibernate LazyInitializationException when working with frame serializers (blazeDS for Flex / GWT serializer)

I am not sure if this is a clear answer in these conditions.

Answer 5

In my opinion, there are no problems with using domain model objects at each level. You said that you do not need all the information. When you are in the JSP, use only the data you need. No one forces you to receive every property. You also said that you need to do calculations related to the properties of the object in order to get the GPA, # students, etc. You have 3 options: creating synthetic properties in the domain model object that return the data you need, complete pleasant and neat; perform calculations either at the controller level or at the service, and expose them through the corresponding getters; or handle it all inside your JSP. You need to get / compile / abort ANYWAY data, so why add extra complexity with DTO.

In addition, with each DTO you create.) An extra class that you must now support, and b.) In the LEAST 1 extra method, somewhere in some class that creates and populates the DTO (DAO, factory method, etc.) d.). More service = unhappy developer in 6 months.

So, there are my arguments against the DTO. I use them, but only in certain scenarios, for example, when I really need to optimize the speed and / or memory usage, and the cost of wetting an object of a full domain model is too high. Web services are a good example of when I prefer to use DTO.

Answer 6

The behavior of a class or its internal methods should not be affected by layers that are not related to their behavior. Pass data, not behavior. Use domain objects in the domain. The website is not a controlled domain, and user interface developers do not need to worry about domain behavior, just data.

The domain must be encapsulated and protected from change by someone not related to the domain’s health.

Leaking behavior is not a good habit.

If this is a small project, he also built the right principles. Thus, we always remember why we do what we do, and not just how.

Answer 7

I think that we should first of all consider the cost of introducing a new layer. Take the DTO, for example, by doing this, we need a mapping. As someone said, translation is evil and should be avoided whenever possible.

On the other hand, I think that there are very few things that you usually should not do. Those who say that all DTOs are evil are mistaken - it always depends on the use case! Are they justified?

And finally, I personally think that domain objects should be released for submission. Imagine what the integration of the gate is. But take Spring MVC, for example - the domain will remain at the application level, probably ...

Answer 8

Currently, the DTO is widely regarded as an anti-pattern, and the council usually "avoids them at all costs."

One of the main advantages of an ORM structure such as Hibernate is that you can use domain objects at all levels and not need a DTO. The caveat, of course, is that you should devote sometime to THINK these relationships: when to use lazy sampling, when to use impatience, etc.