理论：“服务定位器”“IOC容器”“IOC”“DI”

Question

你能帮我解释一些模式的理论吗？我试图描述它们，我已经尽力了，但我认为我的陈述是错误的，所以帮助））。

1) “DI”和“IOC” - 相同。

2) “IOC Container” - 它是一个对象的实例，可以解决以下依赖关系：

void Test()
{
    // create IOC Container to resolve
    // dependences for SomeMethod method
    var container = new SomeContainer();
    container.For(typeof(IEmaleSender), typeof(SuperEmaleSender));

    // Pass IOC Container to resolve dependences in SomeMethod
    SomeMethod(container);
}

void SomeMethod(SomeContainer container)
{
    IEmaleSender emailSender = container.Resolve(IEmaleSender);
    emailSender.SendEmail();
}

3) “服务定位器” - 它类似于包含 Dictionary<Type, object> 的静态对象，其中 value 是键类型的实例。这个静态对象有两种方法：Add 和Get。所以我可以在我的应用程序开始时添加对象并从任何地方请求它：

void Test()
{
    // Assign instanse of SuperEmaleSender to Locator
    SuperEmaleSender emailSender = new SuperEmaleSender()
    SomeLocator.Add(typeof(SuperEmaleSender), emailSender);

    SomeMethod();
}

void SomeMethod()
{
    SuperEmaleSender emailSender = SomeLocator.Get(typeof(SuperEmaleSender));
    emailSender.SendEmail();
}

4) 结合“服务定位器”和“IOC 容器”是一个很好的做法。因此，您可以在应用程序启动时实例化“IOC Container”，并通过“Service Locator”从任何地方请求它。

5) 在 ASP MVC5 中，已包含“服务定位器”。我说的是DependencyResolver。

感谢您的帮助。

Answer 1

至于服务定位器与 IoC 的结合——当你有合适的 IoC 容器时，你真的不应该使用服务定位器（或者在大多数情况下你可能根本不应该使用它），因为 IoC 和 DI 的重点是从类外部传递依赖项并明确指定该类具有哪些依赖项。在内部使用服务定位器会隐藏依赖关系。 Service locator is by some people considered an anti-pattern.

Answer 2

Service Locator 几乎是一种极其原始的依赖注入。它通常只允许您返回单例实例。它不是真正的 DI，因为您必须手动获取实例并手动获取新对象，而不是让 DI 引擎为您完成（新对象并将服务引用注入其中）。 DI 还可以让您更好地控制对象的生命周期。

Answer 3

DI 代表依赖注入，IoC 代表控制反转。 假设您有一个访问数据库的类。该类的职责是插入一个项目，但您需要一个数据库连接来执行此操作。如果类的职责只是插入一个项目，它不会知道如何启动该连接，只知道如何使用它。考虑一下，您会将连接设置为该类的依赖项，将创建该连接的责任传递给任何想要使用它的人。您正在使用依赖注入反转控件，将责任传递给任何知道连接如何工作的人。

您可以使用 IoC 容器来帮助您管理类之间的依赖关系。

您可以查看此问题以获得更详细的答案：Inversion of Control vs Dependency Injection