我遇到了这个问题，是否应该使用new关键字创建jpa实体，或者使用原型范围将实体作为spring组件，并从Application Context获取bean。
我个人认为我们不应该将你的实体作为弹簧组件并自己创建它们而不是从Spring那里询问它。
这意味着实体可以被注入到任何地方但是我们有这个Demeter定律的东西，其中对象应该只与它们的近邻通信。当然，我们可以说，我们只是不在服务中使用它们，而只在DAO服务中使用它们，但我们目前没有大赢家。
我的意思是我喜欢在一个地方集中所有对象构造的想象力。如果有人问，它在哪里创建，我们可以说：“Spring创造了它”。
另一个原因是表可能具有非空列。如果JPA实体是100％与数据库兼容的实体bean，则它至少需要一个不受自动原型创建支持的Constructor-Argument。我们可以删除那个构造函数参数，并将任何非空列从编译时再次移动到运行时，但是如果我们删除那个构造函数参数，我们也会删除fail-fast原则。
依赖 - 倒置 - 原则也有一个原因。我在这里的理由（尊敬地）与Makoto的原因有点不同。 DIP背后的一个想法是
高级模块不应该依赖于低级模块。
您是否同意以这种方式创建的实体是低级模块并且需要它的服务是高级模块的想法？所以我们放弃了DIP的这一部分。
Spring给你的主要好处是依赖注入和控制反转。当您处理JPA实体时，您绝对需要控制其生命周期，而不仅仅是处理级联操作（保存和删除），还为了清晰和理智。
更糟糕的是，这种开发风格绝对与Spring结合在一起;你可以在没有Spring的情况下使用JPA / Hibernate，如果你发现自己处于想要迁移它的位置，如果你的JPA实体通过你的框架连接，你会发现离婚非常非常困难。
你不想让Spring管理这些实体。它增加了代码库本身的显着复杂性，但收效甚微。
你可以做到，但它有意义吗？
不，并且有多种原因。 最明显的一个来自使对象成为bean的第一个原因：
我们应该将实体视为我们想要注入的依赖吗？ 答案当然是否定的。 因此实体不必是豆类。
实体的生命周期由持久化上下文而不是Spring容器处理，你确实不想注入一个实体，但你通常想要在方法中创建它：你自己或通过EntityManager。
所以Spring在这里完全无关紧要。