2

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

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

  1. 实体框架域模型。这是所有真相的来源，也是存储在数据库中的内容。这里Widget知道关于小部件的一切。虽然它是 Code First POCO 模型，但 EF 确实对您需要定义哪些属性以使模型正常工作设置了某些限制。（试图省略外键 ID 只会导致痛苦，IMO。）

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

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

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

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

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

作为一个天生要求系统化和简化事物的人，坦率地说，这一切都让我感到烦恼。真难闻。我无法摆脱我必须错过某些东西的感觉，并且必须有更好/更清洁的方法来处理这个问题。

有哪些策略和工具可以缓解（或自动化？）这种传播？还是这种重复是不可避免的？

我是否以该系统组合在一起的方式与框架作斗争？

4

1 回答 1

0

我认为总体而言，拥有单独的视图模型和 DTO 是一个好主意。他们每个人真的有一个真正的单独的责任。域对象与各种模型和 DTO 之间的映射可能会非常痛苦，所以我建议使用 AutoMapper 之类的东西来处理它。

于 2013-12-04T20:49:42.663 回答