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

查看:23
本文介绍了视图层中的 DTO 或域模型对象?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我知道这可能是一个古老的问题,但更好的做法是什么?在应用程序的所有层中使用域模型对象,甚至在 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 模型对象并使用其自己的自定义创建的模型对象(意味着未绑定到任何数据库会话,始终分离).以上任一场景对严格的模型对象模式是否更有利?在延迟初始化异常等方面,使用 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 combineGpa"的 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 世界中,使用 ViewModel 很常见,对我来说很有意义.

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屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆