Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

DTO or Domain Model Object in the View Layer?

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 directly to them on the JSP (I'm using JSF). Or convert a domain model object into a DTO in the DAO or Service layer and send a lightweight DTO to the presentation layer.

I have been told it makes no sense to use DTOs because changes to the database will result in changes to all your DTOs whereas using Model Objects everywhere will just require changes to the affected model object. However, the ease of use and the lightweight nature of DTOs seems to outweigh that.

I should note that my app uses Hibernate Model Objects AND uses its own custom-created model objects (meaning not bound to any DB session, always detached). Is either of the above scenarios more beneficial to a strict Model Object pattern? Using Hibernate has been a huge PITA with regards to things like Lazy Initialization Exceptions.

I am editing this question in hopes of furthering discussion (not sure if I'm doing this right):

The problem I have with model objects is that they are not flexible at all. A comment below says that the application should be designed so that model objects can be used throughout all layers. Why? If a user wants a piece of ridiculous functionality, am I supposed to tell them, 'well that won't work with model objects'?

Plain and simple, there are just times when model objects won't 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 that information. You just need the teacher's last name, the number of student's they teach this year, and average GPA for all students combined. What would you do in that case? Retrieve the full teacher information and student relationships and then your code gets a count on the List of Students, then computes a total average of all gpas inside? That seems like waaaay more effort than simply creating a DTO with 'String lastName', 'int numStudents', and 'double combinedGpa;

It may sound like my mind has been made up on these, but I have yet to work in an application where model objects can be completely used cleanly in every instance. Regular real-world applications with out-of-the-ordinary user demands just do not work that way.

like image 485
sma Avatar asked Apr 21 '10 03:04

sma


People also ask

Is DTO same as view model?

The canonical definition of a DTO is the data shape of an object without any behavior. ViewModels are the model of the view.

What is the difference between DTO and domain object?

If using anemic data model (i.e. your domain objects don't have any logic), DTO and domain object can be the same object. No. Domain objects have no specific relation to any persistence. In simple words, they are parts to ensure the business logic required to run the application.

Is DTO domain layer?

A DTO is a technical representation that is serializable friendly. As far as I know it is part of Data Layer. Domain Layer includes use cases, repository (not the implementation), and the models (domain model). Data Layer on the other hand includes repository (implementation), data source which includes DTO and Entity.

What is DTO layer?

A DTO is nothing more than a container class that exposes properties but no methods. A data transfer object (DTO) holds all data that is required for the remote call. Your remote method will accept the DTO as a parameter and return a DTO to the client.


1 Answers

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

  1. You'll be tempted to modify your domain object to accommodate things you need in the view layer
  2. Your View layer will contain extra complexity caused by a mismatch between what your domain objects offer and what your view really needs. You might not be able to get around this complexity but it probably doesn't belong in the View layer.

If your domain objects are simple and your views are few, skipping the DTOs might be the simplest thing.

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

like image 177
srmark Avatar answered Oct 07 '22 10:10

srmark