我正在设计一个相当大的系统来管理数据存储库，并通过各种媒体将其出售给用户。为了论证，让我们说这是一个小的小部件和命令目录。我发现设计不满意的一件事是，我发现自己在系统的不同部分有许多并行但不同的对象模型，还有许多代码来管理和互换它们。
更具体一点，到目前为止，我们至少有以下内容：
实体框架域模型。这是所有真相的来源，以及存储在数据库中的内容。这里的Widget知道关于小部件的一切。虽然它是Code First POCO模型，但EF确实会对您需要定义哪些属性进行约束，以使模型正常工作。 （试图忽略外键ID只会导致痛苦，IMO。）
管理员网络应用的视图模型。大多数显示视图只能使用域对象。但并非每个属性都可以直接编辑，有些属性必须以与存储时不同的形式进行编辑，依此类推。
一组基本移动应用使用的网络API的 DTO 。这里的焦点是a）提供（仅）应用程序所需的信息，以及b）定义序列化过程中出现的JSON的形状。输出并不总是与域模型一对一。
我们还在开发一个并行Web API，我们的OEM可以通过它来查看和管理自己的小部件。这些要求与面向移动设备的API或内部管理网站不同，因此此API为Widget或我们的部件订单公开的数据集不会100％匹配。
所有被移动的概念实体都是相同的，但系统的不同部分以不同的方式与它们交互，或者与它们的不同方面交互。添加新字段，或更改验证逻辑，或类似的事情可能需要触及不同命名空间中的一大堆不同Widget类，并调整转换代码。不是概念上的困难，而是单调乏味且容易出错。
即使我们对使用与渲染视图和管理序列化相关的属性来装饰域模型没有美学上的反对意见，实际上通常有多组视图用于实体，或者不止一个API，因此没有一组要编码的指令。
作为一个性质需要系统化和简化事物的人，坦率地说这只是让我感到烦恼。真难闻。我无法摆脱我必须缺少某些东西的感觉，并且必须有更好/更清洁的方法来处理这个问题。
有哪些策略和工具可以缓解（或自动化）这种传播？或者这种重复是不可避免的？
我是否按照系统组合的方式对抗框架？
答案 0 :(得分：0)
我认为总体而言，拥有单独的View Models和DTO是一个好主意。他们每个人都真的有一个单独的责任。域对象与各种模型和DTO之间的映射可能会变得非常痛苦，所以我建议使用类似AutoMapper的东西来处理它。