Seb*_*n K 5 asp.net-mvc domain-driven-design dependency-injection asp.net-mvc-3
我正在阅读Mark Seemann目前的".NET中的依赖注入".我想知道组成DDD ASP.NET MVC应用程序的最佳方法是什么.
在简化的场景中,一般的经验法则是将域模型作为应用程序的核心,并且不会对数据层或表示有任何依赖性.它将暴露Presentation将使用的某些接口(因此依赖)和数据层将实现(因此依赖).所以这一切都很好而且清晰.

但是,现在,当我们撰写应用程序时.对于ASP.NET MVC应用程序,我们将在global.asax(http://blog.ploeh.dk/2011/07/28/CompositionRoot)中进行.我们的组合根将需要依赖所有层,因为它需要注册所有适用的类型.

这使得所有依赖项看起来都很混乱,现在Presentation层有一个对数据访问层的项目引用(在VS术语中).开发人员很容易犯错并直接使用数据形式的数据访问层,这将有效地耦合这些层.
有没有一个干净的方法来解决这个难题?将Composition Root放在表示层之外几乎是很好的,但在MVC中是不可能的.
UPDATE
在提出这个问题后,我找到了一个相关的问题: DAL - > BLL < - GUI +组合根.如何设置DI绑定? 它有一些有意义的解决方案.接受的解决方案几乎是完美的,但我希望组合根在表示层之外,并且参考表示层而不是其他方式.
其中一个原因是,对我来说概念更清晰 - 构图应该在最顶层.另一个原因是,在我的情况下,表示层中已经有许多DI对象(主要是查看模型映射器的域对象),我想将它们组合在一个位置.
这个帖子给了我一些想法,我认为我想做的事情可能是可能的.
实现更高程度封装的一种方法是将域公开为 HTTP 服务,例如 ASP.NET WebAPI。然后 ASP.NET MVC 解决方案将引用此 API。不会有数据访问依赖性,只有对服务的引用。为简单起见,可以将 API 的已发布语言提取到可由 MVC 演示解决方案引用的程序集中。这种方法的缺点是增加了创建和管理服务所涉及的移动部件和步骤。
此外,您所描述的配置是完全可以接受的。通过提取服务获得的封装可能不值得付出代价。开发人员应该有纪律来防止您所描述的那种泄漏。