C# 好的还是坏的统一设计：注入完整的容器还是只注入显式的接口？

这是一个好或坏的设计问题

我发现总是在模块中注入完整的Unity容器非常方便

1）你永远不知道你需要什么资源。 2.）如果需要容器的更多资源，则不需要更改类构造函数

这看起来像这样：

public class ServiceLocator: IServiceLocator
{
    private IUnityContainer _container = null;

    public ServiceLocator(IUnityContainer container)
    {
        _container = container;
    }


    public void DoSomething()
    {
       var x = this._container.Resolve<IXInterface>();
       var y = this._container.Resolve<IYInterface>();      
       x.Do();
       y.Do();
   }
}

public class ServiceLocator: IServiceLocator
{
    private XInterface _x = null;
    private YInterface _y = null;

        public ServiceLocator(Ixnterface x,  IYnterface y)
        {
            _x = x;
            _y = y;
        }


         public void DoSomething()
        {
            _x.Do();
            _y.Do();    
        }
}

我的问题是：

你认为什么是更好的设计

当Unity容器中有所有资源时，为什么只注入显式接口

未来的问题是什么

我所看到的未来唯一的问题是，在未来，你总是必须有一个Unity容器，如果你没有它，你必须重写模块

你觉得怎么样？

编辑：我找到的一些最好的答案是，第一个版本不是依赖注入，而是某种“服务定位器模式”，这可能会导致许多问题

可以在这里找到：

---

在第一种方法中，您需要依赖于所需的接口，并且您正在向容器中添加另一个接口：

var x=this.\u container.Resolve（）；
var y=this._container.Resolve（）；

---

因此，您首先违背了DI的主要原因之一。

我认为这是离题的。但是容器应该只在中使用，而不是注入到每个组件中。每个通过容器或为其创建单例的人都对此感到遗憾。我现在正在听的是，Jimmy Boggard解释了他是如何后悔创建了一个静态的

映射器的，以及他为消除对重复的担忧而经历的痛苦，但我以前搜索过。请评论这个问题，即使它是重复的。也许有些事情以前在其他地方没有说过。谢谢。我从您的回答中了解到的是：第一个解决方案为模块添加了3个依赖项，为容器添加了2个依赖项。第二个解决方案向模块添加2个依赖项，向容器添加2个依赖项。因此，第一个解决方案的依赖性太大了。@Michael，第二个解决方案对容器没有任何依赖性。在某种程度上，您将有一个配置告诉容器您的
ServiceLocator
，但是
ServiceLocator
本身只依赖于
IXInterface
和
IYInterface
，根本不知道容器。谢谢您。我将有两三天的时间进行密集的重构，因为我不想要一个糟糕甚至不可思议的代码设计。昨天我对这个问题有了自己的答案：如果您在没有任何“容器框架”的情况下进行DI，您将永远不会在模块上添加任何您不需要的不必要的依赖项。第二：使用组件的一个重要方面是使它们在其他/新的软件项目中可重用，这样您就不必再编写它们了。您不能确定在另一个软件项目中是否有任何容器框架，但您可以轻松地将独立的组件组合在一起。下面的博文也很好，因为它说，如果您使用某种服务定位器，您将对类使用者隐藏依赖项。如果我只注入容器，没有人知道类真正需要哪些依赖项。谁知道，哪些类需要注册到容器中？
var x = this._container.Resolve<IXInterface>();
var y = this._container.Resolve<IYInterface>();