我应该封装我的IoC容器吗？

Question

我正在尝试决定是否有必要通过额外的努力来封装我的IoC容器.经验告诉我,我应该在我的应用程序和任何第三方组件之间放置一层封装.我只是不知道这是否接近矫枉过正.

我可以想到我可能想要切换容器的情况.例如,我目前的容器不再维护,或者证明不同的容器更轻,性能更好,更符合我的需要.如果发生这种情况,那么我可能需要进行大量的重新布线.

为了清楚起见,我正在考虑封装类型的注册和解决方案.我认为封装解决方案是明智的 - 我希望通常的做法是将helper/util类委托给容器.

编辑:

假设我更喜欢以编程方式为类型安全,编译时检查和可重构性连接我的类型.这是该代码和它的,我正在寻找保护自己从容器上的依赖.

我也一直在为其他几个共享很多相同关系的项目使用IoC容器,但容器很难处理,所以我想要改变.但是,更改意味着我失去了注册码的可重用性.因此,为什么我正在考虑封装.这不是一个巨大的负担,但我会喜欢减轻负担.

我期待:

• 最大限度地减少容器/容器版本更改的影响
• 在可能使用不同容器的项目中提供某种级别的类型注册一致性
• 提供对我有意义的接口方法(RegisterSingleton <T,T>而不是RegisterType <T,T>(SomeLifetimeProvider) - 以Unity为例).
• 随着条件/可伸缩性要求的改变而增加容器,例如在解析/注册期间添加更好的缓存,日志记录等.
• 提供我自己的模型来注册类型映射.
  • 假设我想在程序集/包中创建一堆RegistrationHandler对象,因此我可以轻松地将注册职责分隔到多个类中,并自动拾取这些处理程序,而无需在其他任何地方更改代码.

我意识到这有点主观,所以优点/缺点可能会有所帮助

谢谢!

Answer 1

稍后再做,并且只有在您确实需要更改IOC容器时才这样做.

选择一个非侵入性的IOC容器.也就是说,彼此连接的对象与IOC容器没有任何依赖关系.在这种情况下,没有什么可以封装的.

如果您必须选择一个要求您对容器具有依赖性的IOC容器,请选择具有最简单依赖关系/ API的容器.如果您需要替换此IOC容器(并且您可能不会),请实现将新API桥接到旧API的适配器.

换句话说,让第一个IOC容器成为为任何未来容器定义接口的容器,这样您就不必创建自己的容器,并且可以延迟任何此类工作,直到您绝对需要它为止.

编辑:

我没有看到保证类型安全性的方法:

1. 设计一个相对复杂的Builder模式实现以及可以编写IOC配置文件的访问者实现,或类似的东西.
2. 实现类型安全的IOC配置DSL.(我的选择是否有多个应用程序需要可交换的IOC容器.)