【发布时间】：2019-11-19 20:15:26
【问题描述】：
我正在使用依赖注入和 Unity 容器开发 MVC4 应用程序。我可以通过在 Web 项目中实现 IDependencyResolver 类来解决依赖关系。在支持类库中是否有类似的方法来解决启动时的依赖关系？
【问题讨论】：
标签： dependency-injection unity-container
【发布时间】：2019-11-19 20:15:26
【问题描述】：
在支持类库中是否有类似的方法来解决启动时的依赖关系？
直接调用容器或外观（例如DependencyResolver）是一种称为Service Locator pattern的模式，在Dependency Injection in .NET和Dependency Injection Principles, Practices, and Patterns这本书中都描述为an anti-pattern。
因此，不要从类库项目中的类中调用服务定位器，而是使用dependency injection pattern 在其构造函数中注入类所需的所有依赖项。
【讨论】：
-
在将依赖注入构造函数之前，我需要注册依赖。这在 MVC 中通过在初始化期间实现 IDependencyResolver 接口来处理。我想在程序集启动时使用业务逻辑注册支持类库的依赖项。我正在寻找一个接口或上下文来在类库项目启动时注册依赖项。
-
这些组件在其他程序集中定义并不重要。它们都应该在应用程序的启动路径中注册（在 MVC 中，这是
Application_Start事件）。这个独特的地方被称为Composition Root。 -
好的，这似乎有道理，但这不会导致 MVC 项目依赖于支持的类库项目吗？我有一个 3 层应用程序，UI（MVC 项目）业务（类库）和数据（类库）。我想将依赖项从数据项目注入业务项目，并从业务项目注入 UI 项目。如果我将所有项目的依赖项注册到 UI 项目中，我将需要为业务和数据项目添加对 UI 项目的引用，从而创建一个依赖项。
-
@MahmoudHeretani，阅读DIPP&P 或至少the excerpt 中的服务定位器反模式描述可能会很有用。该模式并不禁止您的特定情况，但它确实限制了您可以在应用程序中直接调用容器的位置。区别在于Composition Root 的概念。
-
感谢@Steven 提供的链接，我会深入了解它们，除此之外我已经开始阅读您的书了