Java 将jpa实体作为spring组件是一个好主意吗

我遇到了这样一个问题：是否应该使用new关键字或 使您的实体成为具有原型范围的spring组件，并从应用程序上下文中获取bean

---

我个人认为，我们不应该让您的实体成为spring组件并自己创建它们，而不是向spring索取。

spring给您的主要好处是依赖注入和控制反转。当您处理JPA实体时，您绝对希望对其生命周期进行控制，这不仅是为了处理级联操作（保存和删除），也是为了清晰和理智

更糟糕的是，这种开发方式绝对适合春天；您可以在没有Spring的情况下使用JPA/Hibernate，如果您发现自己处于想要从它迁移出去的位置，如果您的JPA实体通过框架连接，您会发现这非常非常困难

---

您不想让Spring管理这些实体。它为代码库本身增加了大量的复杂性，但收益甚微。

您可以这样做，但它有意义吗

没有，并且有多种原因。
最明显的一个原因来自将对象变成bean的第一个原因：

<强>是否应该将实体视为要注入的依赖项？< /强> BR> 答案当然是否定的 所以实体不必是bean

实体的生命周期由持久性上下文处理，而不是由Spring容器处理，您确实不希望注入实体，但通常希望在方法中创建实体：您自己或通过

EntityManager

---

所以春天在这里是完全不相关的。

这意味着实体可以被注入到任何地方，但我们有德米特定律，物体应该只与其近邻交流。当然，我们可以说，我们只是不在服务中使用它们，而只在DAO服务中使用它们，但目前我们没有大赢家

我的意思是我喜欢把所有的物体结构集中在一个地方的想象。如果有人问，它是在哪里创造的，我们可以说：“春天创造了它”

另一个原因是表可能有NOTNULL列。如果JPA实体是100%与数据库兼容的实体bean，那么它至少需要一个构造函数参数，而自动原型创建不支持该参数。我们可以删除该构造函数参数，并将任何违反not null列的行为从编译时移动到运行时，但是如果删除该构造函数参数，我们也会删除fail fast原则

依赖倒置原则中也有一个原因。我在这里的理由（恭敬地）与Makoto的理由有一点不同。这次下跌背后的一个想法是

高级模块不应依赖于低级模块

---

您是否同意这样的想法，即以这种方式创建的实体是低级模块，而需要它的服务是高级模块？所以我们松开了DIP的这部分。

不，它们绝对不应该是弹簧组件。春天不会创造它们。JPA/Hibernate可以。而且它们不需要注入任何依赖项。让代码依赖于任何第三方库不是一个“好”主意。Spring尊重命名和注入注释，不需要与Spring联姻。@PeterRader:我有保留意见，如果一个团队有意识地决定使用Spring注入他们的JPA实体，那么它将使用

@Named

或

@inject

。