我已经阅读了很多关于仅在需要时使用模式的信息。我目前正在编写一个非常简单的应用程序，它实现了存储库和服务模式——我现在正在讨论是否使用 DTO 将我的域对象传递给视图。这是一个单页应用程序。
我开始在我的模型中创建 DTO 类，但仍然无法理解它们提供了什么好处。感觉就像我只是无缘无故地复制一切。
什么时候适合使用 DTO？在什么时候它变得必要或有益？任何示例/样本都会很棒。
问问题
8076 次
1 回答
9
我开始在我的模型中创建 DTO 类，但仍然无法理解它们提供了什么好处。
那么在这种情况下，它们很可能不会提供任何好处。坚持最简单的方法总是最好的，因此您可能会尝试不必要地增加复杂性。
我想说，当您只需要传递一些平面数据而不需要复杂的域对象时，DTO 很有用。在我看来，如果可能的话，最好将您的视图直接绑定到您的业务对象。如果没有别的，它会提供一个健全性检查，以确保您的业务对象符合您的使用场景。事实上，这是CSLA 框架（以及其他）所倡导的方法，它专注于业务对象。
我发现自己将域对象转换为 DTO 的最常见场景是：
- 当我对外部服务有一个抽象的依赖（它本身与我的内部域对象不一致）并且我想让服务接口本身非常简单时。我没有在服务层内进行所有翻译，而是让服务层本身使用 DTO 并在两者之间构建一个翻译层。
- 当我通过 AJAX 调用将序列化对象返回给 JavaScript 并且不希望我的域对象的所有额外开销通过网络时。保持 JavaScript 本身更简单，不通过外部网络连接传输不必要的数据等。
- 当我有一个使用各种域对象数据的组合而不是其超集的视图时。在某些情况下，这可能表明该视图代表了一个值得拥有自己的域对象的用例（可能是其他对象的组合，或者可能所有涉及的对象都应该是较小的非聚合根对象的组合，这取决于） ，所以要小心这种情况。但有时只是制作一个中间 DTO 会使代码更简单、更干净。
我认为关键在于将数据从一种形状转换为另一种形状。如果在服务、控制器或视图中进行大量翻译......那么也许该翻译是一个足够大的组件，值得拥有自己的对象。真的，这都是关于关注点分离的。一个好的经验法则是，如果一段代码“出于某种目的重新塑造数据并实现该目的”，那么这段代码正在做两件事。将其分成两段代码可能会更好。DTO 是这两者的通信方式。
有一些工具（例如AutoMapper）可以帮助在志同道合的对象之间转换大量“脚手架”代码。
于 2013-03-01T01:44:27.650 回答