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

Question

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

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

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

Answer 1

  

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

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

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

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

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

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

有一些工具（例如AutoMapper）可以帮助大量“脚手架”代码在志同道合的对象之间进行翻译。