c# - 抽象单例背后的 IoC 容器——做错了吗？

Question

一般来说，我喜欢让应用程序完全不了解 IoC 容器。但是我遇到了需要访问它的问题。为了消除痛苦，我使用了一个基本的单例。在你跑到山上或拔出霰弹枪之前，让我回顾一下我的解决方案。基本上，IoC 单例绝对什么都不做，它只是委托(delegate)给一个必须传入的内部接口(interface)。我发现这使得使用单例的工作不那么痛苦。

下面是 IoC 包装器:

public static class IoC
    {
        private static IDependencyResolver inner;

        public static void InitWith(IDependencyResolver container)
        {
            inner = container;
        }

        /// <exception cref="InvalidOperationException">Container has not been initialized.   Please supply an instance if IWindsorContainer.</exception>
        public static T Resolve<T>()
        {
            if ( inner == null)
                throw new InvalidOperationException("Container has not been initialized.  Please supply an instance if IWindsorContainer.");

            return inner.Resolve<T>();
        }

        public static T[] ResolveAll<T>()
        {
            return inner.ResolveAll<T>();
        }
    }

IDependencyResolver:

public interface IDependencyResolver
    {
        T Resolve<T>();
        T[] ResolveAll<T>();
    }

到目前为止，我已经成功地使用了它几次(也许每隔几个项目一次，我真的更喜欢根本不需要使用它)因为我可以注入(inject)任何我想要的东西:城堡，一个 stub 、假货等

这条路很滑吗？我会在未来遇到潜在的问题吗？

Answer 1

我已经看到甚至 Ayende 在 Rhino Commons 代码中实现了这种模式，但我建议尽可能不要使用它。默认情况下，温莎城堡没有此代码是有原因的。 StructureMap 确实如此，但 Jeremy Miller 一直在远离它。理想情况下，您应该像对待任何全局变量一样怀疑容器本身。

但是，作为替代方案，您始终可以配置容器以将 IDependencyResolver 解析为对容器的引用。这听起来可能很疯狂，但它更加灵活。请记住一个经验法则，一个对象应该调用“new”或执行处理，但不能两者兼而有之。对于“调用新”替换为“解析引用”。