使用 Hibernate 时使用服务和 DAO 获取 DTO 和实体的最佳实践 [关闭]

Question

**1。服务使用：当你看到一个 hibernate spring 教程时，他们都说对于一个实体（例如我的例子中的用户）你必须有一个名为 UserRepository 的存储库，其中包含 find、findAll、delete 等方法。通常 UserRepository 扩展了一些基本存储库界面。

然后你必须添加 UserService，它会注入一个 UserRepository。

一个。我必须有一个由 UserServiceImpl 实现的 UserService 接口吗？从我的角度来看，它没有增加任何价值。我可以让 UserService 成为一个类，并使用 Spring 使用 GCLIB 而不是 JDKInterfaces 创建代理的能力。

b。通过从 UserRepository 复制每个方法并委托给 @Autowired 存储库来编写 UserService 是否正确，然后添加任何其他业务方法？

c。如果我的 UserService 没有任何业务方法，它只是将所有内容委托给 UserRepository，我可以跳过 UserService 并从我的 REST 层直接访问 UserRepository 吗？

d。假设我也有一个地址实体。用户在保存时需要一个地址（这是 one2one 强制性的）。是否可以从 UserService 将 UserRepository 和 AddressRepository 注入其中，在那里建立关系，然后在每个存储库上调用 save ？ （不想使用级联持久化，我想知道没有它我该怎么办，因为在某些情况下你不能使用级联）

2. DTO用法：当你要读取数据时，可以直接通过JPQL（或者Criteria，我更喜欢JPQL）获取实体或者获取DTO。

一个。从我的角度来看，我总是使用 DTO 而不是实体获取。这是因为，我认为 SQL 很简单，如果我必须考虑实体的合并、分离、附加等，我会错过 SQL 的整个简单性，而 ORM 在性能和复杂性方面成为敌人。因此，当我在修改数据时读取数据和实体时，我总是会使用 DTO。你怎么看？

b 。我想从用户实体返回所有列。是否可以有一个 UserDTo 或者我夸大其词并且应该只返回一个 User 实体？我对此有 50% - 50% 的支持。

c。我想从用户部分返回一些列。在这里，我支持 75% 的 DTO 和 25% 的实体。你怎么看？

d。我想返回一些用户列和一些地址列。在这里，我 100% 支持 DTO（尽管我可以加入 fetch Address ）。你怎么看？

亲切的问候，

Answer 1

我会一一回答：

1.a) 是的，确实有道理。服务层是事务边界，它是您通过课程粒度接口向外部世界公开业务逻辑的地方。

1.b) 不，不是。 UserService 定义业务方法，而不是数据访问方法。

1.c) 我仍然会保留服务。

1.d) 当然是。您无需通过实体名称调用服务。按他们所表达的业务逻辑关注点命名。

2.a) 我的规则很简单：计划修改时的实体和只读投影的 DTO。

2.b) 同 2.a.

2.c) 与 2.a 相同。如果您以后需要修改获取的数据，请使用子实体。

2.d) 与 2.a 相同。如果您需要修改数据，请使用实体或子实体。否则，用于只读投影的 DTO。