java - 使用 Hibernate 时使用 Services 和 DAO 获取 DTO 和实体的最佳实践

Question

关闭。这个问题需要更多 focused .它目前不接受答案。












想改进这个问题？更新问题，使其仅关注一个问题 editing this post .

5年前关闭。




Improve this question




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

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

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

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

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

d .假设我也有一个地址实体。用户在保存时需要一个地址(这是 one2one 强制性的)。是否可以从 UserService 将 UserRepository 和 AddressRepository 注入(inject)其中，在那里建立关系，然后在每个存储库上调用 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) 是的，它确实有道理。服务层是事务边界，它是您通过类(class)粒度接口(interface)向外部世界公开业务逻辑的地方。
1.b)不，不是。 UserService 定义业务方法，而不是数据访问方法。
1.c)我仍然会保留服务。
1.d) 当然是。您无需通过实体名称调用服务。通过他们表达的业务逻辑关注点来命名。
2.a)我的规则很简单:当您计划修改实体时，以及只读投影的 DTO。
2.b) 同 2.a。
2.c) 同 2.a。如果您稍后需要修改获取的数据，请使用子实体。
2.d) 同 2.a。如果您需要修改数据，请使用实体或子实体。否则，只读投影的 DTO。