使用Hibernate时获取DTO和实体与服务和DAO的最佳实践

Question

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

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

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

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

c。如果我的UserService没有任何商业方法，它只是委托一切到UserRepository，我可以跳过UserService并直接从REST层访问UserRepoisitory？

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

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

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

b。我想返回用户实体的所有列。有没有UserDTo可以，或者我夸大，应该只是返回一个用户实体？我有50％ - 50％。

c。我想部分返回来自用户的一些列。在这里，我是75％的DTO和25％的实体。你怎么看？

d。我想返回一些用户列和地址列。在这里，我是DTO的100％（尽管我可以加入获取地址）。你怎么看？

亲切的问候，

Answer 1

我会回答他们一个接一个：

1.A）是的，这有一定道理。服务层是事务边界，它是通过一个粗粒度接口将业务逻辑展示给外部世界的地方。不，不是，它不是。UserService定义了业务方法，而不是数据访问方法。

1.c）我仍然保持服务。

1.d）当然是这样。您不需要通过实体名称来调用服务。通过他们所表达的业务逻辑关注来命名它。

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

2.b）与2.a相同。

2.c）与2.a相同。 If you need to modify the fetched data later, then use subentities。

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