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

时间:2016-10-14 22:14:50

标签: c# design-patterns dependency-injection ioc-container service-locator

你可以帮我解释一些模式的理论吗?我试图描述它们,我已尽力了,但我认为我的陈述是错误的,所以帮助))。

1)“DI”和“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是密钥类型的实例。此静态对象有两种方法:AddGet。所以我可以在应用程序启动时添加对象并从任何地方请求它:

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”,并通过“服务定位器”从任何地方请求它。

5)在ASP MVC5中,已经包含“服务定位器”。我在谈论DependencyResolver

感谢您的帮助。

3 个答案:

答案 0 :(得分:3)

至于组合服务定位器与IoC - 当你有合适的IoC容器时,你真的不应该使用服务定位器(或者在大多数情况下你根本不应该使用它),因为IoC的重点DI是从类外部传递依赖关系,并明确指定该类具有的依赖性。在里面使用服务定位器会隐藏依赖项。 Service locator is by some people considered an anti-pattern

答案 1 :(得分:1)

服务定位器几乎是一个非常原始的依赖注入。它通常只允许您返回单例实例。它不是真正的DI,因为您必须手动获取实例并手动获取新对象而不是让DI引擎为您执行此操作(new up对象并将服务引用注入其中)。 DI还可以让您更好地控制对象的生命周期。

答案 2 :(得分:0)

DI代表Depency Injection和IoC for Inversion of Control。 想象一下,你有一个访问数据库的类。该类的责任是插入一个项目,但是您需要一个数据库连接来执行此操作。如果类的责任只是插入一个项目,它就不知道如何启动该连接,只知道如何使用它。考虑到这一点,您将连接设置为该类的依赖关系,将创建该连接的责任传递给任何想要使用它的人。您正在使用依赖注入反转控件,将责任传递给知道连接如何工作的任何人。

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

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