我一直在寻找.NET的各种依赖注入框架，因为我觉得我正在开发的项目将从中受益非浅。虽然我认为我已经很好地掌握了这些框架的功能，但我仍然不清楚如何最好地将它们引入一个大型系统。大多数演示(可以理解)往往是相当简单的类有一个或两个依赖。
我有三个问题…
首先，你如何处理那些常见但不感兴趣的依赖，例如。 ILog，IApplicationSettings，IPermissions，IAudit。对于每个类来说，似乎有些过分，它们在构造函数中作为参数。使用DI容器的静态实例在需要时是否更好？
MyClass(ILog log,IAudit audit,IPermissions permissions,IApplicationSettings settings) // ... versus ... ILog log = DIContainer.Get<ILog>();
第二，如何处理可能使用的依赖项，但创建起来可能很昂贵。示例 – 类可能依赖于ICDBurner接口，但不希望创建具体实现，除非实际使用CD刻录功能。你在构造函数中将接口传递给工厂(例如ICDBurnerFactory)，或者你再次以一种静态方式直接访问DI容器并在需要的时候请求它？
第三，假设你有一个大的Windows窗体应用程序，其中顶层GUI组件(例如MainForm)是潜在的数百个子面板或模态形式的父级，每个子面板或模态形式可能有几个依赖项。这是否意味着MainForm应该被设置为具有所有依赖的子集的所有依赖的超集？如果你这样做，这不会最终创建一个巨大的自我膨胀的怪物，构建每一个类，它可能需要你创建MainForm的时刻，浪费时间和记忆的过程中？
首先：根据需要在你的构造函数中添加简单的依赖。没有必要添加每个类型到每个构造函数，只需添加您需要的。需要另一个，只是展开构造函数。性能不应该是一件大事，因为大多数这些类型可能是单例，因此在第一次调用之后已经创建。不要使用静态DI容器来创建其他对象。而是添加DI容器到自己，所以它可以解析为依赖。所以这样的东西(假设团结的时刻)
原文链接：https://www.f2er.com/javaschema/282584.htmlIUnityContainer container = new UnityContainer(); container.RegisterInstance<IUnityContainer>(container);
这样，您可以只添加一个依赖关系IUnityContainer，并使用它来创建昂贵的或很少需要的对象。主要的优点是，单元测试更容易，因为没有静态依赖。
第二：不需要传入一个工厂类。使用上面的技术，您可以使用DI容器本身在需要时创建昂贵的对象。
三：将DI容器和轻单体依赖项添加到主窗体，并根据需要通过DI容器创建其余。需要更多的代码，但正如你所说的启动成本和内存消耗的mainform将通过屋顶如果你创建一切在启动时间。
