DTO or Domain Model Object in the View Layer?

Question

I know this is probably an age-old question, but what is the better practice? Using a domain model object throughout all layers of your application, and even binding values

Answer 1

Another vote for domain objects. As far as Domain Driven Design is concerned the domain model is the king and should be used where possible. The application should be designed in a way where most layers (bar Infrastructure layer) can use domain objects.

I think of DTOs as useful only where the objects need to be serialised. If there is no transfer over the wire or into an incompatible architecture I would not use them. DTO pattern is useful for keeping serialisation out of the domain object. Considering that UI/Domain interaction does not need serialisation, keep it simple and use the actual objects.

Answer 2

Scenarios when Domain Object are problematic to be sent :

1. you may need aggregated information or other types of 'calculated fields' sent to the UI layer ( in example Flex / GWT ) and don't want to mess the Domain Object
2. you may encounter a need for serializing cyclic object graph ( in your example, if Student had List relation ) , some protocols have problems with that
3. Hibernate LazyInitializationException when dealing with the framework serializers ( blazeDS for flex / GWT serializer)

I'm not sure it's a clear cut answer in those cirumcstances

Answer 3

In my opinion, there's no problem at all with using domain model objects in every layer. You said that you don't need all of the information. When you're in your JSPs, use only the data that you need. No one is forcing you to fetch every property. You also said that you need to make calculations related to the object's properties in order to get GPA, # of students, etc. You have 3 options: create synthetic properties in your domain model object that return the right data for you, wrapped up nice and neat; do the calculations in either the controller or service layer, and expose them through the appropriate getters; or handle it all inside your JSP. You need to retrieve/compile/wrangle the data ANYWAY, so why add more complexity with a DTO.

Additionally, with each DTO, you're creating a.) an extra class you now have to maintain, and b.) at LEAST 1 extra method somewhere in some class that constructs and populates the DTO (DAO, factory method, etc.). More maintenance = unhappy developer 6 months later.

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

Answer 4

I think having DTO is not generally an anti pattern. There are a lot of people and systems using them and the benefit you get is the decoupled view layer that can be designed and modularized independently from the domain model. Although I agree that you should use domain objects where possible there are scenarios where you can get problems when you tie the view layer directly to the domain model.

I have made good experiences with a view model that only wraps around the domain objects and delegates most of the operations to them.This decouples view and domain layer, allows for flexible composition of domain objects and still is not much work to implement since IDEs support delegation pattern.

Answer 5

DTO is widely considered an anti-pattern nowadays, and the advice is usually "avoid them at all costs".

One of the main advantages of an ORM framework like Hibernate, is that you can use domain objects at all levels, and don't really need DTOs. The caveat, of course, is that you have to dedicate sometime to THINK on those relationships: when to use lazy fetching, when to use eager, etc.

Answer 6

One of the reasons to use DTOs is when you need to display information to different types of users. E.g. you have an "account" domain model, and it has some property, e.g. "created_at". Depending on your business logic, you could show account to admins and to users, but users are not really allowed to know about creation date of an account (for some company secret reasons). Serving domain model to both admin and users could be very dangerous, especially if you are using JSON API, but if you split representation into 2 different DTOs - for admins and users, then it will be much safer. I have to say that it will require much more time to deal with and maintain this, but if your app requires this type of security and strictness, then you have no other choice.