MVP 中的模型类只是 POCO（贫血域模型、DTO 或 VM）？它们应该是包含业务逻辑的实体对象吗？答案

【问题标题】：Model classes in MVP are just POCOs (Anemic Domain Model, DTOs, or VM)? Should they be entity objects which contain business logic?MVP 中的模型类只是 POCO（贫血域模型、DTO 或 VM）？它们应该是包含业务逻辑的实体对象吗？
【发布时间】：2020-12-07 05:25:46
【问题描述】：

在以下示例中，模型文件夹下的类只是 POCO。（是 DTO 还是 VM？）

https://github.com/mrts/winforms-mvp

https://markheath.net/post/model-view-presenter-winforms

它们应该是包含业务逻辑的实体对象吗？业务/应用程序逻辑是否应该全部在演示者中？或者实体对象应该在MVP代码所依赖的一些核心模块中？

【问题讨论】：

标签： .net design-patterns architecture domain-driven-design mvp

【解决方案1】：

我认为最好记住，DDD 不仅仅是实施部分的一组战术模式，而是从诸如无处不在的语言之类的战略模式开始> 和 有界上下文。另见https://medium.com/@chatuev/ddd-for-microservices-4778a363c071

因此，DDD 首先是探索您的问题域，通过深入了解它，您可以更好地决定哪些实现模式适合系统的不同部分。这可能是简单的类似 CRUD 的 实现或遵循战术 DDD 模式使用聚合、实体、存储库、值对象等

它们应该是包含业务逻辑的实体对象吗？业务/应用程序逻辑是否应该全部在演示者中？或者实体对象应该在MVP代码所依赖的一些核心模块中？

如果您遵循领域驱动设计中的战术模式，那么 Consumer 模型类应该包含业务逻辑。

所以考虑到这个示例项目中有业务逻辑，Consumer 将是一个所谓的 anemic domain model，因为在这个版本中它是只是一些没有逻辑的数据类。

如果根本没有复杂的业务逻辑，而是有大量的 UI 逻辑和 CRUD 之类的数据操作，那么遵循战术性 DDD 原则可能是矫枉过正，而且额外的努力也不会得到回报。因此，在这种情况下，可能没有贫血域模型，因为根本没有 域模型，而只有 DTO 和视图模型类可以完全满足需求。

【讨论】：