何时在MVC4应用程序中使用DTO(数据传输对象)？

Question

我已经阅读了很多关于仅在需要时使用模式的内容.我目前正在编写一个非常简单的应用程序,它实现了存储库和服务模式 - 我现在正在讨论是否使用DTO将我的域对象传递给视图.这是一个单页面应用程序.

我开始在我的模型中创建DTO类,但仍无法理解它们提供的好处.感觉就像我只是无缘无故地重复一切.

什么时候适合使用DTO？它在什么时候变得必要或有益？任何例子/样本都会很棒.

Answer 1

我开始在我的模型中创建DTO类,但仍无法理解它们提供的好处.

那么在这种情况下很可能就是它们没有提供好处.坚持使用最简单的方法总是最好的,因此您可能会尝试不必要地增加复杂性.

我想说当你需要传递一些平面数据而不需要复杂的域对象时,DTO很有用.在我看来,最好在可能的情况下将您的视图直接绑定到业务对象.如果不出意外,它会提供一个完整性检查,确保您的业务对象符合您的使用场景.实际上,这是CSLA框架(以及其他)专注于业务对象的方法.

我发现自己将域对象翻译成DTO的最常见场景是:

1. 当我对外部服务(它本身与我的内部域对象不一致)有一个抽象的依赖时,我想让服务接口本身变得非常简单.我没有在服务层内进行所有翻译,而是让图层本身使用DTO并在两者之间构建翻译层.
2. 当我通过AJAX调用将序列化对象返回到JavaScript时,并且不希望我的域对象的所有额外开销都通过网络传输.保持JavaScript本身更简单,不通过外部网络连接传输不必要的数据等.
3. 当我有一个视图使用各种域对象的数据的复合,但不是它的超集.在某些情况下,这可能表明此视图表示一个用例,它可以使用自己的域对象(可能是其他对象的组合,或者所涉及的所有对象应该是较小的非聚合根对象的组合,它取决于) ,所以要小心这个场景.但有时只是制作中介DTO可以使代码更简单,更清晰.

我认为关键在于从一种形状的数据到另一种形状的转换.如果在服务,控制器或视图中进行大量翻译......那么也许该翻译是一个足够大的组件,值得拥有自己的对象.这完全取决于关注点的分离.一个好的经验法则是,如果一段代码"为某种目的重新塑造数据并实现这一目的",那么这段代码就是做两件事.可能最好将它分成两段代码.DTO是这两者沟通的方式.

有一些工具(如AutoMapper)可以帮助大量的"脚手架"代码在相似的对象之间进行转换.