视图层中的DTO还是领域模型对象? [英] DTO or Domain Model Object in the View Layer?

问题描述

我知道这可能是一个古老的问题，但是更好的做法是什么?在应用程序的所有层中使用域模型对象，甚至在JSP上直接将值绑定到它们(我正在使用JSF).或将域模型对象转换为DAO或Service层中的DTO，然后将轻量级DTO发送到表示层.

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.

有人告诉我使用DTO是没有意义的，因为对数据库的更改将导致对所有DTO的更改，而在任何地方使用模型对象仅需要对受影响的模型对象进行更改.但是，DTO的易用性和轻巧的特性似乎胜过这一点.

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.

我应该注意，我的应用程序使用了Hibernate Model Objects，并使用了自己的自定义创建的模型对象(意味着不绑定到任何数据库会话，始终是分离的).以上两种情况中的任何一种是否对严格的模型对象模式更有利?对于诸如惰性初始化异常之类的事情，使用Hibernate一直是一个巨大的PITA.

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.

我正在编辑此问题，以希望进一步讨论(不确定我是否做对了):

模型对象的问题在于它们根本不灵活.下面的评论说应设计应用程序，以便可以在所有层中使用模型对象.为什么?如果用户想要一个可笑的功能，我应该告诉他们，那将不适用于模型对象吗?"

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]
}

但是也许您不需要所有这些信息.您只需要老师的姓氏，今年他们教的学生人数以及所有学生的平均GPA即可.在这种情况下，您会怎么做?检索完整的教师信息和学生关系，然后您的代码就可以在学生列表"中计数，然后计算其中所有gpa的总平均值?这似乎比简单地用'String lastName'，'int numStudents'和'double CombinedGpa;创建一个DTO更加费力.

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.

推荐答案

这实际上取决于应用程序的复杂性.将域对象混合到视图层有两个可能的含义:

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

1. 您将很容易修改域对象以适应视图层中所需的内容
2. 您的视图层将包含额外的复杂性，这是由于您的域对象提供的内容与视图实际需要的内容之间不匹配而导致的.您可能无法克服这种复杂性，但它可能不属于View层.

如果您的域对象很简单并且视图很少，那么跳过DTO可能是最简单的事情.

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

另一方面，如果您的域模型可能会演变并变得复杂，并且如果您的视图可能数量众多且变化很大，那么查看特定的对象可能是个好主意.在MVC世界中，使用ViewModels很常见，对我来说很有意义.

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.

这篇关于视图层中的DTO还是领域模型对象?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！