在 ASP MVC 应用程序架构中分离服务和业务层？答案

【问题标题】：Separate Service and Business layers in ASP MVC app architecture?在 ASP MVC 应用程序架构中分离服务和业务层？
【发布时间】：2014-04-12 11:26:00
【问题描述】：

最近几天，当我为新项目做准备时，我阅读了很多关于应用程序架构的内容。到目前为止，我几乎使用过以下架构：

表示层（ASP MVC 控制器）业务层【使用领域模型】存储库

那些使用组合根的依赖注入。

在我前几天阅读的过程中，我发现了很多建议具有以下内容的资源：

表示层服务层业务层存储库

因此，在表示和业务之间有服务层。我唯一能看到的就是自动映射器，因此服务层将充当中间层，为业务层准备输入（模型）。如果这是唯一的好处，那么我不确定我是否会为此使用全新的图层。如果这是服务层的唯一好处，我会牺牲瘦控制器故事并将自动映射器放入控制器中。

所以，问题是……在我缺少的业务层前面设置服务层还有其他好处吗？

任何想法将不胜感激！谢谢

【问题讨论】：

【解决方案1】：

服务层是您的域模型（业务）的薄包装器。您可以使用任何模式（例如 Facade）来创建服务层，因为服务层将负责根据您的要求组合业务逻辑。这有很多方面，但如果您有简单的 CRUD 应用程序，这就足够了。

【讨论】：

感谢您的意见！这不是一个简单的 CRUD 应用程序。另一方面，它是非分布式部署策略。如果它是分布式的，那么我当然会看到明显的优势，因为在这种情况下，服务层可能会通过 WCF 暴露，例如到外面的世界。但在非分布式的情况下，我仍然认为拥有它没有任何优势。
服务层我指的是来自域驱动设计的“域服务层”，而不是分布式系统中的服务。现在，如果您不使用领域服务层并直接公开您的领域模型，那么您的领域模型最终会损坏并最终成为贫血模型。请通过领域驱动设计了解领域模型和贫血领域模型的概念。