[英]Modern Layered Architecture Implementation
我最近读完了Dino Esposito的精彩著作Modern Web Development ,在其中他提出了针对Web应用程序的域驱动分层体系结构的建议。 我一直在努力寻求与以下建议类似的具体建议:
具体参考在基础结构层中进行的IoC。 我了解其背后的原因,这对我来说很有意义,但是您如何在ASP.NET MVC框架的范围内充分实现呢? 若要添加依赖项解析器,您需要实现System.Web.MVC命名空间中存在的IDependencyResolver接口。
在过去的项目中,我通常会在MVC应用程序本身的启动文件夹中实现IoC,但这似乎与布局建议不符。
我不想将其转变为一种观点类型的问题,我正在寻找的是一种可能的,实际的具体方式来实现此模式,而无需将System.Web.MVC命名空间拖到基础结构层。
编辑
为了为建议的体系结构添加一个后续图表,还有令我困惑的部分,似乎Dino的建议确实将IoC容器放入了基础架构程序集:
从根本上来说,您的问题是“我正在寻找一种可行的,实际的,无需将System.Web.MVC命名空间拖到基础结构层即可实现此模式的具体方法”
有一种方法可以做到这一点,它涉及引入一个新的IoC容器库,该库专门用于此目的。
IDependencyResolver
不必是系统范围的分辨率接口,它只是MvC使用的接口。 还有其他IoC容器,其中许多容器提供适配器以注入包装其IoC逻辑的IDependencyResolver
实现。
这允许一些事情:
IDependencyResolver
支持此功能的IoC容器的一些示例:
您可以看到示例的最后一行是:
DependencyResolver.SetResolver(new AutofacDependencyResolver(container));
在该行之后,任何依赖IDependencyResolver
MvC组件IDependencyResolver
将自动获取AutofacDependencyResolver
,该包装将对Autofac容器的调用包装
这是大量c#IoC容器的比较 ,可以帮助您选择适合您的容器 。
我认为,您在过去的项目中仅在Mvc应用程序中使用IoC的做法更为正确,因此您可能已经熟悉以下概念,但是当您考虑从域中引用IoC时,我认为值得探索。
虽然该答案提供了一种方法来执行您要问的事情,但基于该图,我承认我不清楚目的在于依赖域层的IoC解析器的目的是什么,以及为什么需要这样做。
如果发现自己这样做了,则可能是意外使用了“ 服务位置反模式”
如该博客中所述,无需依赖IoC解析器(或定位器),只需依赖您所需的服务,然后让IoC注入适当的实现即可。
理解意图的部分问题是图表本身-人们经常通过将它们放在一些盒子上并将它们连接起来来绘制图表-却始终不清楚线条的含义。 他们是依赖链吗? 它们是执行顺序吗? 从域模型框到基础结构层的实际标签有一条线是什么意思??? 是一无所有吗? 还是在此未说明可能的依赖关系?
系统中唯一应直接引用IoC解析器的部分是组合根,它实际上是应用程序的入口点。 第一部分“连接对象图”-实际上,它注册了如何解析所有可能的依赖关系,从依赖的接口到适当的具体实现。
然后,它解析入口点对象(或注册IDependencyResolver
以便Mvc可以解析入口点对象,也就是控制器)。 解析输入对象后,它将自动解析其所有依赖关系,在解析下一层依赖关系的过程中,依此类推,直到到达没有依赖关系的类为止。 如果您正在执行DDD,则可能是您的域层。
由于您对DDD感兴趣,因此可以理解,域层不应依赖于域层中未定义的任何内容。 如果确实需要利用基础结构组件(例如存储库)的服务,请使用单独的接口并将该接口放在域层中,而将实现放在一个具体的持久层中。
虽然我认为没有必要从域层(或实际上是任何层)引用IoC解析器/定位器,但我仍然认为采用单独的专用IoC容器库很有用,如上所述。
该值位于有关如何配置服务的一些更灵活的选项中,包括一些基于漂亮约定的自动配置。
取决于域层中的IoC库,可能值得的一个原因是将注册和配置逻辑与正在配置的服务一起放置,这可以帮助结构和组织IoC依赖项注册。 但是,仅仅因为您依赖IoC程序集来允许构造您的注册,并不意味着您应该使用IoC解析器/定位器。
声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.