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 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.

Answer 1

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 2

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 3

Maybe Gilead might help you: http://noon.gilead.free.fr/gilead/

Answer 4

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