hibernate 业务对象可以用作干净架构中的实体吗？答案

【问题标题】：Can hibernate business objects be used as entities in a clean architecture?hibernate 业务对象可以用作干净架构中的实体吗？
【发布时间】：2017-02-11 11:47:22
【问题描述】：

在我们的项目中，我们使用 eclipse hibernate 插件生成的类来实现持久性。生成的类具有以下结构。

MyClass extends BaseMyClass //POJO's, that are refenced in the hbm
files

MyClassDAO extends BaseMyClassDAO //DAO objects that use hibernate
session objects to provide CRUD API's for working with DB

我的问题是，如果我们使用映射文件中使用的 POJO 类作为最内层的实体，会不会违反 Uncle Bobs 的干净架构。

在这种情况下，特定于休眠的 DAO 类将属于最外层，而 UseCases 层将通过提供要实现的接口与该层进行通信。

【问题讨论】：

那些 POJO 是从 DB 模式生成的吗？
是的，它们是从数据库模式生成的
所以这不是业务模型，这是 DB 模型 :) 如果您想坚持六边形或洋葱架构类型，则此 DB 模型不应该是您应用程序的核心域模型。
有道理，谢谢
同样使用 POJO 可能会导致 anemic model

标签： java hibernate onion-architecture hexagonal-architecture clean-architecture

【解决方案1】：

鲍勃叔叔在展示这张幻灯片时在挪威的一次演讲中提到了这一点：

鲍勃叔叔说：

在线上方没有休眠。如果您使用的是 Hibernate，它会低于该行。 应用程序不知道您正在使用该框架。它低于线。 Hibernate 是一个可爱的工具。它非常适合从数据库中收集数据并将其转换为数据结构。非常好！但是您不希望您的应用程序知道您正在使用它。你把所有的东西都放在这条线下面。

Robert C Martin - Clean Architecture, NDC 2012 (53:53 - 54:18)

因此，如果您在实体上使用 Hibernate 注释，您会将域对象与数据库层的详细信息混合在一起。

一些开发人员认为注解不是那么强的依赖关系，因为如果它们在运行时不可用，它们就根本不存在。没错，但您还必须考虑其他原则。

如果您在实体上放置 Hibernate 注释，实体类现在有两个不同的更改原因：域逻辑和数据库映射。这违反了single responsibility principle。因此，数据库映射会影响您的域对象。

我想有很多混乱，因为重载的术语实体。当 Bob 大叔谈到实体时，他指的是领域。在 Hibernate 中实体表示数据库记录。

这就是为什么我通常使用术语“域实体”或“数据库实体”来区分它们。

【讨论】：