在自己的 Java 框架中支持多个 DI 容器
Support multiple DI containers in own Java framework
在我自己的多用途Java框架中,如何在不依赖具体DI容器的情况下使用依赖注入?也就是说,任何应用程序都应该能够使用我的框架,无论它是使用 CDI、Spring 还是 Guice 本身。
以下所有情况都应该是可能的:
- 让我的框架将依赖项注入应用程序
- 用于将依赖项注入我的框架的应用程序
- 我的框架的一个组件将依赖项注入另一个组件
您必须为您需要的所有 DI 操作和您可能想要使用的每个具体实例的实现提出一个最小公分母接口。
您的对象中不能有任何 DI 引擎特定的注释,因此您必须外部化所有配置并对所有对象使用 setter 或构造函数注入。
就我个人而言,我认为这是在浪费时间。 DI 应该是一种商品。我看不到切换 DI 引擎的充分理由。您更有可能选择满足您需求的产品并坚持使用。
JSR 330: Dependency Injection for Java 是依赖注入社区内共识程度最高的规范,因此得到以下支持:
- Spring 从 3.0 版开始:http://spring.io/blog/2009/09/29/spring-framework-3-0-rc1-released/,
- 在 Guice 开始版本 3.0: https://github.com/google/guice/wiki/JSR330,
- 在 CDI(JSR 299, JSR 346) specification which leverages JSR 330 thus supported by the Weld and OpenWebBeans 实现中。
这使得 JSR 330 成为跨依赖注入框架具有可移植性的最佳共同点。这显然是以功能范围为代价的。
在我自己的多用途Java框架中,如何在不依赖具体DI容器的情况下使用依赖注入?也就是说,任何应用程序都应该能够使用我的框架,无论它是使用 CDI、Spring 还是 Guice 本身。
以下所有情况都应该是可能的:
- 让我的框架将依赖项注入应用程序
- 用于将依赖项注入我的框架的应用程序
- 我的框架的一个组件将依赖项注入另一个组件
您必须为您需要的所有 DI 操作和您可能想要使用的每个具体实例的实现提出一个最小公分母接口。
您的对象中不能有任何 DI 引擎特定的注释,因此您必须外部化所有配置并对所有对象使用 setter 或构造函数注入。
就我个人而言,我认为这是在浪费时间。 DI 应该是一种商品。我看不到切换 DI 引擎的充分理由。您更有可能选择满足您需求的产品并坚持使用。
JSR 330: Dependency Injection for Java 是依赖注入社区内共识程度最高的规范,因此得到以下支持:
- Spring 从 3.0 版开始:http://spring.io/blog/2009/09/29/spring-framework-3-0-rc1-released/,
- 在 Guice 开始版本 3.0: https://github.com/google/guice/wiki/JSR330,
- 在 CDI(JSR 299, JSR 346) specification which leverages JSR 330 thus supported by the Weld and OpenWebBeans 实现中。
这使得 JSR 330 成为跨依赖注入框架具有可移植性的最佳共同点。这显然是以功能范围为代价的。