关于c#:理论:“服务定位器”“IOC容器”“IOC”“DI”

theory: “Service Locator” “IOC Container” “IOC” “DI”

你能帮我研究一些模式的理论吗?我试着描述它们,我尽了最大努力,但我认为我的陈述是错误的,所以帮助)。

1)"DI"和"IOC"-相同。

2)"IOC容器"-它是一个对象的实例,可以解决如下依赖关系:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
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,其中值是键类型的实例。这个静态对象有两种方法:AddGet。因此,我可以在应用程序启动时添加对象,并从任何地方请求它:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
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容器",并通过"服务定位器"从任何地方请求它。

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

谢谢你的帮助。


至于服务定位器和IOC的结合——当你有合适的IOC容器时,你真的不应该使用服务定位器(或者在大多数情况下,你根本不应该使用它),因为IOC和DI的整个点是从类外部传递依赖关系,并明确地指定这个类具有哪些依赖关系。在内部使用服务定位器将隐藏依赖项。服务定位器被一些人认为是反模式的。


服务定位器几乎是一个非常原始的依赖注入。它通常只允许您返回单例实例。它不是真正的DI,因为您必须手工获取实例和手工获取新的up对象,而不是让DI引擎为您完成(新的up对象并将服务引用注入其中)。DI还为您提供了对对象生命周期的更多控制。


DI代表依赖注入,IOC代表控制反转。假设您有一个访问数据库的类。该类的职责是插入一个项,但您需要一个数据库连接来这样做。如果类的职责只是插入一个项,它将不知道如何启动该连接,只知道如何使用它。考虑到这一点,您将把连接设置为该类的依赖项,将创建该连接的责任传递给任何想要使用它的人。您正在使用依赖注入反转控件,将响应性传递给任何知道连接如何工作的人。

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

您可以看到这个问题以获得更详细的答案:控制反转与依赖注入