依赖注入 – Ioc/DI – 为什么我必须在入口应用程序中引用所有图层/程序集?

前端之家收集整理的这篇文章主要介绍了依赖注入 – Ioc/DI – 为什么我必须在入口应用程序中引用所有图层/程序集?前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
(相关这个问题, EF4 + MVC3: LazyLoading and ProxyCreation)。

我是新的DI与我一起承担…我明白容器是负责实例化所有我注册的类型,但为了这样做,它需要一个引用我的解决方案中的所有DLL和他们的引用。

如果我不使用DI容器,我不需要在我的MVC3应用程序中引用EntityFramework库,只有我的业务层,将引用我的DAL / Repo层。

我知道,一天结束时所有的DLL都包含在bin文件夹,但我的问题是必须通过“添加引用”在VS中明确引用它,以便能够发布具有所有必要的文件的WAP …

If I wasn’t using a DI container,I wouldn’t have to reference EntityFramework library in my MVC3 app,only my business layer which would reference my DAL/Repo layer.

是的,这正是DI工程这么难以避免的情况:)

使用紧密耦合的代码,每个库可能只有几个引用,但是这些引用再次有其他引用,创建一个深层的依赖关系图,如下所示:

因为依赖图是深层的,这意味着大多数库会沿着很多其他依赖项拖动。在图中,库C沿着图书馆H,图书馆E,图书馆J,图书馆M,图书馆K和图书馆N拖动。这使得难以独立地重复使用每个图书馆,例如in unit testing

然而,在松散耦合的应用程序中,通过移动对Composition Root的所有引用,依赖图被严重扁平化:

如绿色所示,现在可以重用库C,而不拖动任何不需要的依赖。

然而,所有的说,有许多DI容器,你不必添加硬引用所有必需的库。相反,您可以使用基于约定的装配扫描(首选)或XML配置的形式使用晚期绑定。

但是,当您这样做时,您必须记住将程序集复制到应用程序的bin文件夹,因为这不会自动发生。就个人而言,我很少发现值得额外的努力。

猜你在找的设计模式相关文章