c# - 在不需要许多并行对象模型的情况下设计 MVC/EF 系统

Question

我正在设计一个相当大的系统来管理数据存储库并通过各种媒体将其提供给用户。为了争论起见，假设它是一个包含小部件和订单的大目录。我对设计感到不满意的一件事是，我发现自己在系统的不同部分有许多并行但不同的对象模型，并且有很多代码来管理和相互转换它们。

更具体地说，到目前为止我们至少有以下几点:

1. Entity Framework 领域模型。这是所有真相的来源，也是存储在数据库中的内容。 Widget 了解有关小部件的所有信息。虽然它是一个 Code First POCO 模型，但 EF 确实对您需要为模型正常工作定义的属性施加了某些限制。 (试图省略外键 ID 只会导致痛苦，IMO。)

2. 管理网络应用的 View 模型。大多数显示 View 可以只使用域对象。但并非每个属性都应该可以直接编辑，有些属性必须可以以不同于存储形式的形式进行编辑，等等。

3. 一组 DTO 用于一组 native 移动应用程序使用的 Web API。这里的重点是 a) 提供(仅)应用程序需要的信息，以及 b) 定义序列化过程中产生的 JSON 的形状。输出并不总是与域模型一一对应。

4. 我们还在开发一个并行网络 API，我们的 OEM 可以通过它查看和管理他们自己的小部件。要求与面向移动的 API 或内部管理站点不同，因此此 API 为 Widget 公开的数据集或我们的零件订单不会 100% 匹配。

移动的都是相同的概念实体，但系统的不同部分与它们的交互方式不同，或者与它们的不同方面交互。添加新字段或更改验证逻辑或类似的事情可能需要接触不同 namespace 中的一大堆不同的 Widget 类，并调整翻译代码。概念上并不难，但乏味且容易出错。

即使我们对使用与渲染 View 和管理序列化相关的属性装饰领域模型没有美学上的反对意见，一个实体也经常有不止一组 View ，或者不止一个 API，所以没有t 一组指令进行编码。

作为一个天性要求系统化和简化事物的人，坦率地说，这一切都让我烦恼。真难闻。我无法摆脱这样的感觉，即我一定遗漏了一些东西，并且必须有更好/更干净的方法来处理这个问题。

有哪些策略和工具可以减轻(或自动化？)这种传播？或者这种重复是不可避免的吗？

我是否按照这个系统的组合方式与框架作斗争？

Answer 1

我认为总体而言，拥有单独的 View 模型和 DTO 是一个好主意。他们每个人都有真正独立的责任。域对象与各种模型和 DTO 之间的映射会变得非常痛苦，因此我建议使用 AutoMapper 之类的工具来处理它。