我已经使用 StructureMap 一年多了。一直以来,我都有一个名为 IoC 的包装类,它看起来像这样
class IoC {
public static T GetInstance<T>()
{
return (T)GetInstance(typeof(T));
}
public static IEnumerable<T> GetAllInstances<T>()
{
return ObjectFactory.GetAllInstances<T>();
}
public static IEnumerable GetAllInstances(Type type)
{
return ObjectFactory.GetAllInstances(type);
}
public static object GetInstance(Type type)
{
return ObjectFactory.GetInstance(type);
}
public static void Inject<T>(T obj)
{
ObjectFactory.Inject(obj);
}
}
我添加了包装器,假设我可能想在某个时间点更改 IoC 容器。在这一点上,我认为这很糟糕。一个原因是:我不能在我的代码中使用 ObjectFactory 来做其他有趣的事情,我必须使用这个包装器。另一件事是:我们的代码不应该真正独立于 DependencyInjection 容器。
使用这种方法的优点/缺点是什么?
最佳答案
出于这个原因,Common Service Locator项目已开发。它是对 DI 框架的抽象,它定义了一个与您的 IoC
非常相似的接口(interface)。类(class)。我什至开发了Simple Service Locator图书馆;一个直接实现 Common Service Locator 接口(interface)的 DI 库。
所以从这个意义上说,对 DI 框架进行抽象并不奇怪。但是,当正确(并且完全)进行依赖注入(inject)时,想法是相应地调整应用程序的设计,在应用程序根目录中配置容器,并且最好在应用程序中只有一个位置来组装类型(阅读: GetInstance
被调用)。对于 ASP.NET MVC 应用程序,这将是 ControllerFactory
.对于 ASP.NET WebForms 应用程序,您通常需要覆盖 PageHandlerFactory .
当您遵守这些规则时,没有理由使用这样的抽象,因为无论如何您只是在应用程序中的一个位置调用容器。但是,如果这对您不可行,请使用 Common Service Locator或者您自己的抽象是另一种选择。
但是,在您决定让您的代码依赖于 IoC 库的抽象之前,请退后一步,因为这会导致很多问题和 is seen as an anti-pattern一般来说。从代码中回调容器:
关于dependency-injection - 为您的 IoC 提供包装器是个好主意吗?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/4263975/