理论："Service Locator" "IOC Container" "IOC" "DI"

Question

你能告诉我一些模式的理论吗?我已经尽力描述他们了，我已经尽力了，但是我认为我的陈述是错误的，所以请帮忙。

1)"DI"one_answers"IOC"是一样的。

2)"IOC容器"——它是一个对象的实例，可以解析依赖关系，如:

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)将"服务定位器"one_answers"IOC容器"结合使用是一个很好的做法。因此，您可以在应用程序启动时实例化"IOC容器"，并通过"服务定位器"从任何地方请求它。

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

谢谢你的帮助。

Answer 1

至于将服务定位器与IoC相结合—当您拥有适当的IoC容器时，您真的不应该使用服务定位器(或者在大多数情况下根本不应该使用它)，因为IoC和DI的全部意义在于从类外部传递依赖项，并显式指定该类具有哪些依赖项。在内部使用服务定位器将隐藏依赖项。有些人认为服务定位器是一种反模式。

Answer 2

服务定位器几乎是一个极其原始的依赖注入。它通常只允许返回单例实例。它不是真正的DI，因为你必须手动获取实例，手动创建up对象，而不是让DI引擎为你做这些(创建up对象并向其中注入服务引用)。DI还使您能够更好地控制对象的生命周期。

Answer 3

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

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

你可以看到这个问题的更详细的答案:控制反转vs依赖注入