设计模式 – 害怕使用依赖注入框架

我一直在阅读依赖注入框架.我真的爱上了将问题分开并让对象做核心工作的想法 – 这无疑是一个优秀而长久的设计原则！

然而,我对DI框架的阅读越多,我就越担心：
1)他们“自动”解决依赖关系的方式
2)关于配置文件中引入的极端复杂性

在第2点,我看到我的客户花费数百万美元来培训产品上的人,其中重要的部分是如何“不”触摸配置文件.管理员现在担心这些配置文件.

不过,我看到另一种称为服务定位器的模式,我可以很好地在应用程序开始时组装我想要的所有“全局”服务(可能是应用程序主机或应用程序上下文或其他).使这个服务定位器在全球范围内可用,瞧！

但是,当我根据某些标准(已知谁？)需要多种类型的“全局”服务时,我发现使用服务定位器方法时灵活性会降低！

所以,在这里我比以前更加困惑于采取哪个方向.虽然我非常喜欢设计原则,但现有框架的复杂性让我失望！

我的担忧是真的吗？别人都有同感吗？如果是这样,对于如此大规模压倒性的“框架”,还有什么好的选择吗？

正如Nate所说,“魔术”是可选的;如果需要,您可以手动配置所有内容.

我最初(或永远！)避免配置文件,并在代码中配置容器.这往往更容易阅读和维护.大多数情况下,您不需要对配置进行即时更改.客户无法触摸配置文件,因为它们不存在.

服务定位器有缺点;例如,他们倾向于将您的类耦合到定位器类/框架.一个好的DI框架可以让你使用Plain Old Objects;您的项目中可能只有一个实际使用DI / IoC框架的类.

StructureMap和Unity都非常简单;试一试.从小处开始.

这是Unity的一个非常简单的例子(包括内联配置)：

using Microsoft.Practices.Unity;

static void Main()
{
    using (IUnityContainer container = new UnityContainer())
    {
        container.RegisterType<IRobot, MrRoboto>();

        Console.WriteLine("Asking Unity container to give us a Model...");

        Model model = container.Resolve<Model>();
        model.MoveRobot();
    }
}

// class Model

public Model(IRobot robot)
{
    // Unity will hand the constructor an instance of MrRoboto!
}