为 IoC 提供一个包装器是个好主意吗？

发布于 2024-10-04 15:30:35 字数 829 浏览 6 评论 0原文

我使用 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 容器。

使用这种方法的优点/缺点是什么？

原文

I have been using StructureMap for more than a year now. And all this time I used to have a wrapper class called IoC which looked like this

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);
    }
}

I added the wrapper assuming that I might want to change the IoC container at some point down the line. At this point I am thinking this is bad. One reason is: I cannot use ObjectFactory in my code to do other interesting things, I have to use this wrapper. The other thing is: Our code shouldn't really have to be independent of the DependencyInjection container.

What are the pros/cons of using this approach?

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

梦开始←不甜 2024-10-11 15:30:35

为此，开发了公共服务定位器项目。它是对 DI 框架的抽象，它定义了一个非常类似于您的 IoC 类的接口。我什至开发了 Simple Service Locator 库；一个 DI 库，它是公共服务定位器接口的直接实现。

因此从这个意义上说，对 DI 框架进行抽象并不奇怪。然而，当正确（且完全）执行依赖注入时，其想法是相应地调整应用程序的设计，在应用程序根目录中配置容器，并且最好在应用程序中只有一个位置来组装类型（阅读：调用 GetInstance）。对于 ASP.NET MVC 应用程序，这将是 ControllerFactory。对于 ASP.NET WebForms 应用程序，您通常需要重写 PageHandlerFactory< /a>.

当您遵循这些规则时，没有理由使用这样的抽象，因为无论如何您只是在应用程序中的单个位置调用容器。但是，如果这对您来说不可行，则可以使用公共服务定位器或您自己的抽象作为替代方案。

但是，在决定让代码依赖于 IoC 库的抽象之前，请退后一步，因为这会导致很多问题，并且一般被视为反模式。从代码中回调到容器：