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

Question

**1.服务用法:当你看到一个hibernate spring教程时,他们都说对于一个实体(例如我的用户)你必须有一个名为UserRepository的存储库,其中包含find,findAll,delete等方法.通常,UserRepository扩展了一些基础知识库接口.

然后你必须添加UserService,它注入一个UserRepository.

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

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

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

d.假设我也有一个地址实体.保存时用户需要一个地址(强制要求为one2).从UserService可以在其中注入UserRepository和AddressRepository,在那里设置关系然后在每个存储库上调用save吗？(不想使用级联持久,我想知道如果没有它我将如何做,因为在某些情况下你不能使用级联)

2. DTO用法:当您想要读取数据时,您可以通过JPQL(或Criteria,我更喜欢JPQL)直接获取实体或获取DTO.

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

b.我想从User实体返回所有列.是否可以使用UserDTo或我夸大其词并且应该返回用户实体？我50% - 50%.

c.我想从User返回部分列.在这里,我是75%DTO和25%实体.你怎么看？

d.我想返回一些User列和一些Address列.在这里,我100%为DTO(虽然我可以加入获取地址).你怎么看？

亲切的问候,

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用于只读投影.