ioc-container - 我应该封装我的 IoC 容器吗？

Question

想要改进这篇文章？提供这个问题的详细答案，包括引文和解释为什么你的答案是正确的。没有足够细节的答案可能会被编辑或删除。








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

我可以想到我可能想要切换容器的情况。例如，我当前的容器停止维护，或者另一个容器被证明更轻/性能更佳，更适合我的需求。如果发生这种情况，那么我可能需要进行很多重新布线。

需要明确的是，我正在考虑对类型的注册和解析进行封装。我认为封装分辨率是不费吹灰之力的——我希望将一个助手/实用程序类委托(delegate)给容器是一种常见的做法。

编辑:

假设是我更喜欢以编程方式连接我的类型以实现类型安全、编译时检查和可重构性。我希望保护自己免受此代码及其对容器的依赖。

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

我正在寻找:

尽量减少容器/容器版本变化的影响

在可能使用不同容器的项目之间提供某种程度的类型注册一致性

提供对我有意义的接口(interface)方法(RegisterSingleton 而不是 RegisterType ( SomeLifetimeProvider ) - 以 Unity 为例)。

随着条件/可扩展性要求的变化例如扩展容器在解析/注册期间添加更好的缓存、日志记录等。

提供我自己的模型来注册类型映射。

假设我想在一个程序集/包中创建一堆 RegistrationHandler 对象，因此我可以轻松地将注册职责分离到多个类并自动拾取这些处理程序，而无需在其他任何地方更改代码。

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

谢谢!

Answer 1

稍后再做，并且仅当您确实需要更改 IOC 容器时。

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

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

换句话说，让第一个 IOC 容器定义任何 future 容器的接口(interface)，这样您就不必发明自己的容器，并且您可以延迟任何此类工作，直到您绝对需要它为止。

编辑:

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

设计一个相对复杂的 Builder 模式实现以及编写 IOC 配置文件的访问者实现，或类似的东西。

实现类型安全的 IOC 配置 DSL。 (如果我有多个需要可交换 IOC 容器的应用程序，我会选择。)