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

Posted 2023-02-24

【中文标题】何时在 MVC4 应用程序中使用 DTO（数据传输对象）？ [复制]

【英文标题】：When to use DTOs (Data Transfer Objects) in MVC4 Applications? [duplicate]

【发布时间】：2013-02-15 10:20:24

【问题描述】：

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

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

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

【问题讨论】：

链接的问题不是这个问题的重复。这是关于在 DTO 或域对象（模型）之间进行选择的问题，而链接的问题通常是关于 DTO。

【参考方案1】：

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

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

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

我发现自己将域对象转换为 DTO 的最常见情况是：

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

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

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

【讨论】：

非常感谢大卫。如果您确实使用 DTO，您的存储库层会处理吗？或者您会在您的服务层中专门使用一个方法来转换您的对象（以将 GETTING 与 TRANSFORMING 分开）？

@RobVious：我不在我的存储库中使用 DTO，不。我倾向于认为存储库基本上是一个用于持久化和检索域对象的工厂，最好只是根对象（可能在内部延迟加载或急切加载它们的子对象，具体取决于各种因素）。一般来说，我的 DTO 尽可能靠近代码的外围。 （例如，仅在视图中使用或仅在对外部供应商的后端 Web 服务调用中使用。）

非常感谢大卫提供的详细信息。