DTO vs VM - 使用还是不使用？答案

【问题标题】：DTO vs VM - To use or not to use?DTO vs VM - 使用还是不使用？
【发布时间】：2016-04-15 13:43:29
【问题描述】：

在 asp.net (webapi+mvc) 项目中，我有许多 dto 作为 BLL 的公共接口。此外，我的大多数视图模型都与适当的 dto 相同。

智能书籍告诉我们，我们必须分离这种模型，但在项目中，我认为这种解决方案没有任何好处。只有数百个无用的代码和许多愚蠢的错误。

那么 - 在可能的情况下使用 DTO 作为视图模型是否正确？该解决方案的正面和负面影响是什么？

【问题讨论】：

【解决方案1】：

数据传输对象只是要在逻辑和物理边界之间传输的数据的子集或超集。他们无法提供行为。它们只是数据。

另一方面，视图模型是数据和行为的混合体，因为它们是给定视图的逻辑部分。

由于 DTO 和 VM 是涵盖不同用例的模式，因此您最终可能会得到无用的数据和行为，并且您可能会添加不需要的依赖项。

例如，DTO 可用于域层和应用层。如果您在单个类中同时使用 DTO 和 VM 概念，则最终可能会强制域项目添加对 UI 库的引用以便能够构建它。我会尽量避免这种情况。

此外，您知道有一个名为继承的面向对象的概念，它可以帮助您保持干燥（不要重复自己）：

public class Base {}

public class Dto : Base {}
public class ViewModel : Base {}

总之，您可以通过继承共享 DTO 和视图模型的共同点，并避免代码重复。

【讨论】：

【解决方案2】：

感谢 Matías Fidemraizer 的详细回答。除此之外，我还发现了一些实用且必要的应用程序。

在将 VM 用作独立实体的情况下，您可以增加额外的灵活性。最常见的情况是前端数据的格式和/或结构发生微小变化。第二种情况 - 您的 VM 可以从多个 DTO 对象中组合信息，因此您可以保留您的 bll 代码而不进行任何更改或最小化它们。这就是 S.O.L.I.D.有效。

但最有用的部分是单元测试。您可以更轻松地测试您的 bll，因为您的 DTO 对象可以简单明了。您也不应该害怕映射错误。

【讨论】：