我应该封装我的IoC容器吗？ [英] Should I encapsulate my IoC container?

问题描述

我正在尝试决定是否需要付出额外的努力来封装我的IoC容器。经验告诉我，我应该在我的应用程序和任何第三方组件之间放置一层封装。我只是不知道这是否会导致过度杀伤。

我能想到我可能想要切换容器的情况。例如，我当前的容器不再维护，或者其他容器被证明更轻巧/性能更好，更符合我的需求。如果发生这种情况，那么我可能会需要做很多重新布线。

要清楚，我正在考虑封装注册， 类型的解析。我认为封装分辨率是不费吹灰之力的-我希望让助手/ util类委派给容器是常见的做法。

编辑：

假设我更喜欢以编程方式连接我的类型，以进行类型安全，编译时检查和重构。这是 this 代码及其对容器的依赖性，我正在保护自己。

我也一直在使用IoC容器对于其他几个有着很多相同关系的项目，但是容器很难使用，所以我想改变。但是，更改意味着我失去了注册码的可重用性。因此，为什么我要考虑封装。 b

我希望减轻负担。

• 最小化容器/容器版本更改的影响


• 在可能使用不同容器的项目中提供一定程度的类型注册一致性


• 提供对我有意义的接口方法（以Unity为例，以RegisterSingleton< T，T>而非RegisterType< T，T>（SomeLifetimeProvider））。


• 根据条件/可扩展性要求的变化对容器进行扩容，例如在解析/注册过程中添加了更好的缓存，日志记录等。


• 提供我自己的模型来注册类型映射。
  
  
  
  
  • 说我想在程序集/程序包中创建一堆RegistrationHandler对象，因此我可以轻松地将注册职责划分为多个类，并自动提取这些处理程序而无需在其他任何地方更改代码。
  
  

我意识到这有点主观，因此优点/缺点可能会有所帮助

谢谢！

解决方案

稍后再做，只有在您确实需要更换IOC容器时。

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

如果必须选择一个需要对容器具有依赖关系的IOC容器，请选择一个具有最简单的依赖关系/ API的容器您可以。如果您需要替换此IOC容器（可能不会），请实现将新API桥接到旧API的适配器。

第一个IOC容器是定义将来任何容器的接口的容器，这样您就不必发明自己的容器，并且可以将此类工作中的任何一个延迟到您绝对需要它为止。

编辑：

我看不到任何一种保证类型安全性的方法：

1. 设计Builder模式的相对复杂的实现以及将编写IOC配置文件或类似内容的访问者实现。


2. 实现类型安全的IOC配置DSL。 （如果我有多个需要可交换IOC容器的应用程序，则是我的选择。）

I'm trying to decide whether or not it makes sense to go through the extra effort to encapsulate my IoC container. Experience tells me that I should put a layer of encapsulation between my apps and any third-party component. I just don't know if this is bordering on overkill.

I can think of situations where I might want to switch containers. For instance, my current container ceases to be maintained, or a different container is proven to be more light-weight/performant and better fits my needs. If this happens, then I'll potentially have a lot of re-wiring to do.

To be clear, I'm considering encapsulation of the registration and resolution of types. I think it's a no-brainer to encapsulate resolution - I'd hope it's common practice to have a helper/util class delegating to the container.

EDIT:

The assumption is that I prefer to wire-up my types programmatically for type-safety, compile-time checking and refactorability. It's this code and its dependency on the container that I'm looking to protect myself from.

I've also been using an IoC container for several other projects that share a lot of the same relationships, but the container is a pain to work with so I want change. But, a change means I lose the reusability of the registration code. Hence, why I'm contemplating encapsulation. It's not a huge burden, but one that I'd, nevertheless, like to mitigate.

I'm looking to:

• Minimize the impact of change in containers / versions of containers
• Provide some level of type-registration consistency across projects that may use different containers
• Provide interface methods that make sense to me (RegisterSingleton<T,T> rather than RegisterType<T,T>( SomeLifetimeProvider ) - using Unity as an example).
• Augment the container as conditions/scalability requirements change e.g. adding better caching, logging, etc during resolution/registration.
• Provide my own model for registering type mappings.
  • Say I want to create a bunch of RegistrationHandler objects in an assembly/package and so I can easily segregate registration responsibilities across multiple classes and automatically pickup these handlers without changing code anywhere else.

I realize this is a bit subjective, so pros/cons might be helpful

Thanks!

解决方案

Do it later, and only if you actually have the need to change IOC containers.

Pick an IOC container that is non-invasive. That is, one where the objects being connected to each other don't have any dependencies on the IOC container. In this case, there's nothing to encapsulate.

If you have to pick an IOC container that requires that you have dependencies on the container, choose one with the simplest dependencies/API you can. If you need to replace this IOC container (and you probably won't), implement adapters that bridge the new API to the old one.

In other words, let the first IOC container be the one that defines the interfaces for any future container so that you don't have to invent your own, and you can delay any of this sort of work until you absolutely need it.

EDIT:

I don't see a way of guaranteeing type-safety short of either:

1. Designing a relatively complex implementation of the Builder pattern along with visitor implementations that would write IOC configuration files, or something equivalent.
2. Implementing a type-safe IOC configuration DSL. (My choice if I had multiple apps that required swappable IOC containers.)

这篇关于我应该封装我的IoC容器吗？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！