在asp.net(webapi + mvc)项目中,我有很多dto作为我的BLL的公共接口。此外,我的大多数视图模型与适当的dtos相同。DTO vs VM - 使用还是不使用?
智能书籍告诉我们,我们必须分开这种模型,但在项目上我看不出这个解决方案的好处。只有数百个无用的代码有很多愚蠢的错误。
所以 - 在可能的情况下使用DTO作为视图模型是否正确?这种解决方案的积极和消极影响是什么?
在asp.net(webapi + mvc)项目中,我有很多dto作为我的BLL的公共接口。此外,我的大多数视图模型与适当的dtos相同。DTO vs VM - 使用还是不使用?
智能书籍告诉我们,我们必须分开这种模型,但在项目上我看不出这个解决方案的好处。只有数百个无用的代码有很多愚蠢的错误。
所以 - 在可能的情况下使用DTO作为视图模型是否正确?这种解决方案的积极和消极影响是什么?
数据传输对象只是要在逻辑边界和物理边界之间传输的数据的子集或超集。他们不能提供行为。他们只是数据。
在另一方面,视图模型是数据和行为的混合,因为它们是给定视图的逻辑端。
因为DTO和VM是涵盖不同用例的模式,所以最终会产生无用的数据和行为,并且可能会添加不需要的依赖关系。
例如,DTO可以在域和应用程序层中使用。如果您在单个类中同时使用DTO和VM概念,则最终可以强制域项目添加对UI库的引用以构建它。我会尽可能避免这种情况。
另外,你知道有所谓的继承一个面向对象的概念,它可以在这里为您提供帮助,以保持干爽(不要重复自己):
public class Base {}
public class Dto : Base {}
public class ViewModel : Base {}
总之,你可以分享DTO和通过继承来查看模型的共同点,并避免代码重复。
Thx toMatíasFidemraizer的详细解答。除此之外,我发现了几个实用和必要的应用程序。
在使用虚拟机作为单独的实体的情况下,您添加了一个额外的灵活点。最常见的情况是前端数据的格式和/或结构变化很小。第二种情况 - 您的VM可以编写来自多个DTO对象的信息,因此您可以保留您的Bll代码而无需任何更改或最小化它们。 S.O.L.I.D.作品。
但最有用的部分是单元测试。你可以更容易地测试你的bll,因为你的DTO对象可以简单明了。你也不应该被映射错误所困。
'DTO' **作为**基类如何?简单的将VM转换为基类生成DTO(不需要复制任何东西)。 – Sinatr
@Sinatr由于我是ortodox,我不想让下面的陈述成为一个真相:'if(vm is Dto)':\ –