我们希望将逻辑从我们的超重控制器转移到更全面的域，以生成瘦的控制器。
我们有一个关于如何构建可以为控制器提供正确信息的域模型的问题，以便可以填充视图模型。
我们的数据库第一解决方案具有以下层级：
•UI（目前使用MVC的Web项目）
•域名
•存储库
•数据访问层 - 实体框架
•数据（指向SQL Server的数据库项目）
假设我们有各种各样的视图需要具有特定实体的不同数据量的视图模型，例如
• OrderBasic 查看模型 - 只是ID，标题和日期
• OrderWithCustomer 查看模型 - 以上加上客户实体的客户名称和电话号码
• OrderWithLines 查看模型 - OrderBasic以及订单行列表及其信息
•etc
我们的选择似乎是：
创建与这些类似的域模型。这似乎不对，因为域模型受到各个视图要求的影响，而且我们也在复制代码。 / p>
为每个实体创建一个域模型，其中包含可能需要的所有信息。这对于某些视图而言似乎不利于性能，更多信息正在填充并传输到客户端而不是需要。
作为2，但具有单独或参数化的域方法，只填充必填字段。这可能更高效，但意味着模型有时不完整。
有更好的方法吗？什么是最佳做法？
谢谢，
克里斯。
答案 0 :(得分：2)
域模型是互连对象的图形，它们相互通信并满足您的业务需求并封装业务规则。还有Domain Services封装了业务工作流程和/或计算/算法。
当您对这些域对象进行建模时，除了您的业务和规则之外，您不应该关心其他任何事情。不应该关心数据库或视图的样子。
您的架构中也缺少Application Layer，其中您封装了应用程序的用例（您可以认为，如果您更改应用程序，也会更改用例）。
应用层位于UI（包括MVC控制器）和域层以及编排实体和/或域服务之间，以实现某些用例。
从App层返回一些DTO对象（不是数据库本身的实体！），然后将该DTO中的信息转换为非常友好的UI模型对象（以这样的方式对其进行转换）只需在HTML中进行简单的直接数据绑定。
我在多个项目中实现了相同的架构（可能需要很小的调整），我得到了很好的结果，包括没有更多模型状态验证的瘦控制器，1调用App层以及DTO和视图模型之间的一些粘合代码
这里有很多值得讨论的问题，根据您自己的环境和非功能性要求，方法可能会有所不同，因此请始终对您实际在做什么以及是否对您的特定情况有所了解
P.S。你可以在这里找到一些好的指南（记住依赖规则）：http://blog.8thlight.com/uncle-bob/2012/08/13/the-clean-architecture.html