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

Question

这个问题在这里已经有了答案:





What is a Data Transfer Object (DTO)?

(12 个回答)


9年前关闭。




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

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

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

Answer 1

I started to create the DTO classes in my model but still can't understand what benefit they provide.

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

我想说，当您只需要传递一些平面数据而不需要复杂的域对象时，DTO 很有用。在我看来，如果可能的话，最好将您的 View 直接绑定(bind)到您的业务对象。如果没有别的，它会提供一个健全性检查，以确保您的业务对象符合您的使用场景。确实，这正是 the CSLA framework 所提倡的方法。 (除其他外)专注于业务对象。

我发现自己将域对象转换为 DTO 的最常见场景是:

当我对外部服务有一个抽象的依赖(它本身与我的内部域对象不一致)并且我想让服务接口(interface)本身非常简单时。我没有在服务层内进行所有翻译，而是让服务层本身使用 DTO 并在两者之间构建一个翻译层。

当我通过 AJAX 调用将序列化对象返回给 JavaScript 并且不希望我的域对象的所有额外开销通过网络时。保持 JavaScript 本身更简单，不通过外部网络连接传输不必要的数据等。

当我有一个使用各种域对象数据的组合而不是其超集的 View 时。在某些情况下，这可能表明该 View 代表了一个值得拥有自己的域对象的用例(可能是其他对象的组合，或者可能所有涉及的对象都应该是较小的非聚合根对象的组合，这取决于) ，所以要小心这种情况。但有时只是制作一个中间 DTO 会使代码更简单、更干净。

我认为关键在于将数据从一种形状转换为另一种形状。如果在服务、 Controller 或 View 中进行大量翻译......那么也许该翻译是一个足够大的组件，值得拥有自己的对象。真的，这都是关于关注点分离的。一个好的经验法则是，如果一段代码“出于某种目的重新塑造数据并实现该目的”，那么这段代码正在做两件事。将其分成两段代码可能会更好。 DTO 是这两者的通信方式。

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