依赖注入 – 对具有许多依赖关系的类使用依赖注入框架

前端之家收集整理的这篇文章主要介绍了依赖注入 – 对具有许多依赖关系的类使用依赖注入框架前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
我一直在寻找.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容器到自己,所以它可以解析为依赖。所以这样的东西(假设团结的时刻)
IUnityContainer container = new UnityContainer();
container.RegisterInstance<IUnityContainer>(container);

这样,您可以只添加一个依赖关系IUnityContainer,并使用它来创建昂贵的或很少需要的对象。主要的优点是,单元测试更容易,因为没有静态依赖。

第二:不需要传入一个工厂类。使用上面的技术,您可以使用DI容器本身在需要时创建昂贵的对象。

三:将DI容器和轻单体依赖项添加到主窗体,并根据需要通过DI容器创建其余。需要更多的代码,但正如你所说的启动成本和内存消耗的mainform将通过屋顶如果你创建一切在启动时间。

猜你在找的设计模式相关文章