根据Uncle Bob,实体层应该对数据库一无所知。那么JPA注解呢?它们不违反作者提出的架构吗?如果有,如何在JPA中使用这些实体?
szqfcxe21#
在非ORM的世界中,一个干净的架构将(或可能)涉及到DAO接口,DAO实现知道如何从数据库(或任何其他源)检索数据,并将其转换为域对象并返回。上层将使用DAO(通过接口)检索这些对象。这将允许您为不同的数据库创建不同的DAO实现,并且您可以更改数据库,而无需打扰软件的其余部分。在JPA/ORM的世界里,如果你愿意,你可以绕过很多。您可以使用实体类作为域对象,以数据库不可知的方式创建实体类(即例如,不使用任何数据库特定的NativeQueries)。既然您的实体与数据库无关,您可以在服务层中使用NamedQueries,而不是创建DAO。最后,您需要有一些了解数据库的层,但在JPA的情况下,它甚至不成立。您的实体是Java对象,JPA实现层负责将它们转换为数据库或从数据库转换。结论:在软件开发中很少有普遍真理,你可以和十几个叔叔交谈,听到十几个版本的基本相同的“故事”。
NativeQueries
NamedQueries
vulvrdjw2#
我认为您的域层应该保持不使用JPA注解。将来,您可以用NoSQL实现替换JPA实现,这将使JPA注解变得无关紧要。您可以在持久层中使用JPAorm.xml来定义Map,而不是JPA注解。这将使您的域层保持干净。
orm.xml
2条答案
按热度按时间szqfcxe21#
在非ORM的世界中,一个干净的架构将(或可能)涉及到DAO接口,DAO实现知道如何从数据库(或任何其他源)检索数据,并将其转换为域对象并返回。上层将使用DAO(通过接口)检索这些对象。
这将允许您为不同的数据库创建不同的DAO实现,并且您可以更改数据库,而无需打扰软件的其余部分。
在JPA/ORM的世界里,如果你愿意,你可以绕过很多。您可以使用实体类作为域对象,以数据库不可知的方式创建实体类(即例如,不使用任何数据库特定的
NativeQueries
)。既然您的实体与数据库无关,您可以在服务层中使用NamedQueries
,而不是创建DAO。最后,您需要有一些了解数据库的层,但在JPA的情况下,它甚至不成立。您的实体是Java对象,JPA实现层负责将它们转换为数据库或从数据库转换。
结论:在软件开发中很少有普遍真理,你可以和十几个叔叔交谈,听到十几个版本的基本相同的“故事”。
vulvrdjw2#
我认为您的域层应该保持不使用JPA注解。将来,您可以用NoSQL实现替换JPA实现,这将使JPA注解变得无关紧要。
您可以在持久层中使用JPA
orm.xml
来定义Map,而不是JPA注解。这将使您的域层保持干净。