Question

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

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

那么 - 将DTO用作可能的视图模型是否正确？这个解决方案有什么积极和消极的影响？

Answer 1

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

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

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

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

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

public class Base {}

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

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

Answer 2

向MatíasFidemraizer致谢，详细解答。除此之外，我还发现了一些实用和必要的应用程序。

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

但最有用的部分是单元测试。你可以更轻松地测试你的bll，因为你的DTO对象可以简单明了。你也不应该为绘制错误而烦恼。