model - View 层中的 DTO 还是域模型对象？

Question

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

我被告知使用 DTO 没有任何意义，因为对数据库的更改将导致所有 DTO 的更改，而在任何地方使用模型对象只需要对受影响的模型对象进行更改。然而，DTO 的易用性和轻量级特性似乎更重要。

我应该注意，我的应用程序使用 Hibernate 模型对象并使用自己的自定义创建的模型对象(意味着不绑定(bind)到任何数据库 session ，始终分离)。上述两种情况是否对严格的模型对象模式更有利？就延迟初始化异常等问题而言，使用 Hibernate 是一个巨大的 PITA。

我正在编辑这个问题，希望能进一步讨论(不确定我这样做是否正确):

我对模型对象的问题是它们根本不灵活。下面的评论指出，应用程序的设计应使模型对象可以在所有层中使用。为什么？如果用户想要一个荒谬的功能，我是否应该告诉他们，“这不适用于模型对象”？

简单明了，模型对象有时无法工作。您可能有:

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 returned Gpa 创建 DTO 要花费更多的精力；

听起来我已经决定了这些，但我还没有在一个应用程序中工作，模型对象可以在每个实例中完全干净地使用。具有非常规用户需求的常规现实应用程序就无法以这种方式工作。

Answer 1

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

1. 您可能会想要修改域对象以适应 View 层中所需的内容
2. 您的 View 层将包含额外的复杂性，这是由于域对象提供的内容与 View 真正需要的内容不匹配而导致的。您可能无法解决这种复杂性，但它可能不属于 View 层。

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

另一方面，如果您的领域模型可能会发展并变得复杂，并且您的 View 可能数量众多且多种多样，那么查看特定对象可能是一个好主意。在 MVC 世界中，使用 ViewModel 很常见，并且对我来说很有意义。