我正在尝试确定花费额外的精力来封装 IoC 容器是否有意义。经验告诉我，我应该在我的应用程序和任何第三方组件之间放置一层封装。我只是不知道这是否已经过分了。
我能想到我可能想要切换容器的情况。例如，我当前的容器停止维护，或者不同的容器被证明更轻量/高性能并且更适合我的需求。如果发生这种情况，那么我可能需要重新布线很多工作。
需要明确的是，我正在考虑注册的封装and类型的解析。我认为封装解析是理所当然的——我希望将 helper/util 类委托给容器是常见的做法。
EDIT:
假设我更喜欢以编程方式连接我的类型，以实现类型安全、编译时检查和可重构性。它是this代码及其对我希望保护自己免受的容器的依赖。
我还在其他几个项目中使用了 IoC 容器，这些项目共享许多相同的关系，但容器使用起来很痛苦，所以我想要改变。但是，更改意味着我失去了注册码的可重用性。因此，为什么我正在考虑封装。这不是一个巨大的负担，但我还是想减轻它。
我正在寻找：
- 最大限度地减少容器/容器版本变更的影响
- 跨可能使用不同容器的项目提供某种程度的类型注册一致性
- 提供对我有意义的接口方法（RegisterSingleton 而不是 RegisterType( SomeLifetimeProvider ) - 以 Unity 为例）。
- 随着条件/可扩展性要求的变化而增强容器，例如在解析/注册期间添加更好的缓存、日志记录等。
- Provide my own model for registering type mappings.
- 假设我想在程序集/包中创建一堆 RegistrationHandler 对象，这样我就可以轻松地跨多个类隔离注册职责，并自动拾取这些处理程序，而无需在其他任何地方更改代码。
我意识到这有点主观，所以优点/缺点可能会有所帮助
Thanks!
稍后再执行，并且仅当您确实需要更改 IOC 容器时才执行。
选择一个非侵入式的 IOC 容器。也就是说，相互连接的对象对 IOC 容器没有任何依赖性。在这种情况下，没有什么可以封装的。
如果您必须选择一个需要对容器具有依赖项的 IOC 容器，请选择一个具有最简单的依赖项/API 的容器。如果您需要替换此 IOC 容器（您可能不会），请实现将新 API 桥接到旧 API 的适配器。
换句话说，让第一个 IOC 容器成为defines任何未来容器的接口，这样您就不必发明自己的接口，并且您可以推迟任何此类工作，直到您绝对需要它为止。
EDIT:
我看不出有什么方法可以保证类型安全：
- 设计相对复杂的 Builder 模式实现以及可写入 IOC 配置文件或等效文件的访问者实现。
- 实现类型安全的 IOC 配置 DSL。 （如果我有多个需要可交换 IOC 容器的应用程序，我的选择。）
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
