时间戳

首页 > 解决方案 > 除了管理用户会话，Java SE/EE 中的 CDI 是什么？

java - 除了管理用户会话，Java SE/EE 中的 CDI 是什么？

问题描述

我了解 CDI 在 JavaEE Web 应用程序中的作用，它们帮助在 bean 之间传递用户会话数据。在没有用户会话的情况下，是否有充分的理由在 Java SE 或 Java EE 应用程序中使用 CDI？

标签： javacdi

解决方案

似乎对什么是 CDI 存在误解。我将解释它是什么，然后介绍一些用例及其好处。

什么是 CDI？

CDI 代表“上下文和依赖注入”。它是依赖注入的 JEE 框架。更多信息可在项目的 github 教程中找到。我跳过了依赖注入的解释，有兴趣的读者可以查一下，例如在 wikipedia 上。

依赖注入有什么好处？

部署依赖注入的主要好处是减少摩擦：通过将依赖注入到一个类中，该类与其依赖解耦，并且可以在不更改代码的情况下交换依赖。我在这个答案中给出了一个深入的例子。

依赖注入还可以带来更简洁的架构：定义 REST 端点的类注入必要的服务。作为回报，这些服务会注入必要的存储库/DAO。三层架构是最典型的架构，但不一定是唯一/正确的形式。但是请记住，架构是

  • a) 活着，即随着项目的发展而变化
  • b) 应该始终与项目团队一起决定或至少讨论过的事情。如果团队不喜欢架构，它就不会遵循它，从而使其无用。
  • c) 主观度量。很少有人会发现一种架构是最好的架构的情况。大多数时候，这是一个品味问题。

主要基于依赖注入的架构/原理示例是SOLID 原理和六边形架构。

减少耦合带来的另一个好处是更好的可测试性。通过注入依赖项的模拟，可以单独测试单个服务。

结束语

拥有权利的同时也被赋予了重大的责任。软件工程并不是要将一切与其他一切分离。大多数时候，它决定了哪里需要去耦，哪里需要耦合。过多的抽象和解耦会导致难以维护的难以理解的混乱。举个例子：尽管我很喜欢 CDI 事件，但它们往往会掩盖业务逻辑的实际工作流程，尤其是当事件在多个地方被触发和观察时。

在技​​术说明上，应该避免现场注入。DI 框架必须使用反射以使场注入可行。仅此一项就应该是一个交易破坏者。此外，类的依赖关系变得模糊。如果添加或删除依赖项，仍将创建 bean，可能具有null另一个 bean 应该存在的值。setter 注入也是如此。这就是为什么构造函数注入被认为是三种方法中最干净的。

推荐阅读