应用架构建议答案

【问题标题】：Application Architecture Advice应用架构建议
【发布时间】：2012-08-04 00:33:00
【问题描述】：

我一直在研究用于分层 MVC 应用程序的各种模式，需要一些建议。我目前拥有的是以下内容：

1) POCO 领域模型，完全没有业务逻辑，所以基本上是一个贫乏的领域模型。
2) 带有 Repository 层的 EntityFramework 交还域对象。
3）服务层，现在我不确定这是应用服务层还是领域服务层，但基本上它是一个针对领域模型的API。所有业务逻辑都驻留在这一层并确保域对象有效，然后将其交给存储库以通过 EF 持久化回数据库。
4) ASP.NET MVC 应用程序，该应用程序与服务层对话以获取它需要的对象。

我喜欢它的工作方式，因为它提供了与域模型的单点交互，但我认为我需要的是服务层和 mvc 应用程序之间的一层。该层的职责是将域对象与控制器可以交互的视图模型进行转换，以获得视图所需的确切数据，并将填充的域对象提供回服务层。会不会是应用服务层，上面提到的服务层是领域服务层？

我使用 AutoMapper 将域对象获取到视图模型中，但我不确定将它们返回到域对象的标准。

任何建议或想法都会很棒。

【问题讨论】：

这个描述在流行语上有点长，细节上有点短。但是，即使您充实了它，这也不是很适合 SO 的那种问题。作为一个设计问题，它有点过于开放和主观。
+1 尽管我不认为这个问题严格符合 SO 的指导方针，即一个好的问题应该是什么（例如，非常广泛，没有示例代码），但我还是投了赞成票。我为这些完全相同的问题而苦苦挣扎，希望您能得到一些好的答复。

标签： asp.net-mvc-3 architecture repository-pattern service-layer

【解决方案1】：

虽然理论上，您的域层（尤其是如果您使用 POCO）类非常适合在控制器和视图中使用，但在实践中，总是存在这些极端情况和差异。通常，控制器和视图处理的对象是您的域模型 POCO 的简化，或者是您的应用服务层提供/理解的 POCO 的不同聚合。

因此，我不建议构建单独的层，而是建议将视图模型的方法添加到要发送到应用程序服务的域层对象中。

例如，如果您有User Domain Level 类和UserModel View Model，我会主张创建User ToUser() 实例方法和UserModel UserModel.FromUser(User user) 静态方法来处理转换。您还可以在其中混合和匹配其他视图模型以创建域对象。

【讨论】：