（与这个问题相关，EF4：为什么启用延迟加载时必须启用代理创建？ https://stackoverflow.com/questions/9500642/ef4-mvc3-with-windsor-castle-ioc-di-navigation-properties-not-loading).
我是 DI 新手，所以请耐心等待。我知道容器负责实例化我的所有注册类型，但为了做到这一点，它需要引用我的解决方案中的所有 DLL 及其引用。
如果我不使用 DI 容器，则不必在 MVC3 应用程序中引用 EntityFramework 库，只需引用我的业务层，该层将引用我的 DAL/Repo 层。
我知道最终所有 DLL 都包含在 bin 文件夹中，但我的问题是必须通过 VS 中的“添加引用”显式引用它，以便能够发布包含所有必要文件的 WAP。
如果我没有使用 DI 容器，则不必在 MVC3 应用程序中引用 EntityFramework 库，只需引用我的 DAL/Repo 层的业务层。
是的，这正是 DI 努力避免的情况:)
通过紧密耦合的代码，每个库可能只有几个引用，但这些引用又具有其他引用，从而创建了深层依赖关系图，如下所示：
由于依赖关系图很深，这意味着大多数库都会拖累许多其他依赖关系 - 例如在图中，库C拖着库 H、库 E、库 J、库 M、库 K and 图书馆N。这使得独立于其余库重用每个库变得更加困难 - 例如在单元测试中 https://blog.ploeh.dk/2011/11/10/TDDImprovesReusability.aspx.
然而，在松散耦合的应用程序中，通过将所有引用移至成分根 https://blog.ploeh.dk/2011/07/28/CompositionRoot.aspx, the 依赖图严重扁平化:
如绿色所示，现在可以重复使用库C而不拖拽任何不需要的依赖项。
然而，尽管如此，对于许多 DI 容器，您并不需要have添加对所有必需库的硬引用。相反，您可以使用后期绑定采用基于约定的程序集扫描（首选）或 XML 配置的形式。
但是，当您这样做时，必须记住将程序集复制到应用程序的 bin 文件夹中，因为这不再自动发生。就我个人而言，我很少觉得值得付出额外的努力。
该答案的更详细版本可以在这段摘录 https://freecontent.manning.com/dependency-injection-in-net-2nd-edition-understanding-the-composition-root/从我的书中依赖注入、原则、实践、模式 https://manning.com/seemann2/.
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
