DTO vs VM - 使用还是不使用？
DTO vs VM - To use or not to use?
在 asp.net (webapi+mvc) 项目中，我有许多 dto 作为 public 接口连接到我的 BLL。此外，我的大多数视图模型都与适当的 dto 相同。
聪明的书告诉我们必须分离这种模型，但在项目中我看不到这种解决方案的好处。只有数百个无用的代码，有很多愚蠢的错误。
所以 - 在可能的情况下使用 DTO 作为视图模型是否正确？该解决方案的正面和负面影响是什么？
数据传输对象只是要在逻辑和物理边界之间传输的数据的子集或超集。他们无法提供 行为 。它们只是数据。
另一方面，视图模型是数据和行为的混合，因为它们是给定 视图 的逻辑方面。
由于 DTO 和 VM 是涵盖不同用例的模式，您最终可能会得到无用的数据和行为，并且可能会添加不需要的依赖项。
例如，DTO既可以在域层也可以在应用层使用。如果您同时使用在单个 class 中具体化的 DTO 和 VM 概念，您最终可能会强制域项目添加对 UI 库的引用以便能够构建它。我会尽可能避免这种情况。
此外，您知道有一个面向对象的概念叫做继承，它可以在这里帮助您保持 DRY（不要重复自己）：
public class Base {}
public class Dto : Base {}
public class ViewModel : Base {}
总而言之，您可以通过继承共享 DTO 和视图模型的共同点，避免代码重复。
感谢 Matías Fidemraizer 的详细解答。除此之外，我还发现了几个实用且必要的应用程序。
如果将 VM 用作单独的实体，则可以增加额外的灵活性。最常见的情况是前端数据的小变化格式 and/or 结构。第二种情况 - 您的 VM 可以从多个 DTO 对象中组合信息，因此您可以保留 bll 代码而不进行任何更改或将它们最小化。就是这样了S.O.L.I.D。有效。
但最有用的部分是单元测试。你可以更容易地测试你的 bll，因为你的 DTO 对象可以简单明了。你也不应该害怕映射错误。
在 asp.net (webapi+mvc) 项目中，我有许多 dto 作为 public 接口连接到我的 BLL。此外，我的大多数视图模型都与适当的 dto 相同。
聪明的书告诉我们必须分离这种模型，但在项目中我看不到这种解决方案的好处。只有数百个无用的代码，有很多愚蠢的错误。
所以 - 在可能的情况下使用 DTO 作为视图模型是否正确？该解决方案的正面和负面影响是什么？
数据传输对象只是要在逻辑和物理边界之间传输的数据的子集或超集。他们无法提供 行为 。它们只是数据。
另一方面，视图模型是数据和行为的混合，因为它们是给定 视图 的逻辑方面。
由于 DTO 和 VM 是涵盖不同用例的模式，您最终可能会得到无用的数据和行为，并且可能会添加不需要的依赖项。
例如，DTO既可以在域层也可以在应用层使用。如果您同时使用在单个 class 中具体化的 DTO 和 VM 概念，您最终可能会强制域项目添加对 UI 库的引用以便能够构建它。我会尽可能避免这种情况。
此外，您知道有一个面向对象的概念叫做继承，它可以在这里帮助您保持 DRY（不要重复自己）：
public class Base {}
public class Dto : Base {}
public class ViewModel : Base {}
总而言之，您可以通过继承共享 DTO 和视图模型的共同点，避免代码重复。
感谢 Matías Fidemraizer 的详细解答。除此之外，我还发现了几个实用且必要的应用程序。
如果将 VM 用作单独的实体，则可以增加额外的灵活性。最常见的情况是前端数据的小变化格式 and/or 结构。第二种情况 - 您的 VM 可以从多个 DTO 对象中组合信息，因此您可以保留 bll 代码而不进行任何更改或将它们最小化。就是这样了S.O.L.I.D。有效。
但最有用的部分是单元测试。你可以更容易地测试你的 bll，因为你的 DTO 对象可以简单明了。你也不应该害怕映射错误。