我使用Spring Boot和Spring Data。
我不想把存储库层和服务层分开
所以我有了带CRUD方法和一些Spring Data方法的UserRepository
- 查找全部
- findBy用户名
我也有业务方法的UserService。
- checkPassword（字符串登录，字符串密码）
- businessMethodAction（字符串用户名）
这是我的问题：
在我的控制器中，我必须从UserService调用方法，有时还要从UserRepository调用方法。目前，我在我的控制器中注入这两者，并调用服务或存储库
@Inject
UserService userService;
@Inject
UserRepository userRepository;
@RequestMapping("{username}")
private void myMethod(@PathVariable String username){
return userRepository.findOne(username);
}
@RequestMapping("{username}/doBusineesAction")
private void myMethod(@PathVariable String username){
return userService.doLogicalThin(username);
}我之所以这么问，是因为我混淆了注入这两者，以及调用同一类中的一个或另一个
另一方面，这将意味着在服务层中复制这样的方法
public User findOne(String username){
return userRepository.findOne(username);
}你的意见是什么？
8条答案
按热度按时间r3i60tvu1#
控制器层不应该直接调用存储库。您应该始终使用服务层，因为服务层封装了围绕该调用的业务逻辑。仅仅因为目前没有任何业务逻辑，并不意味着你应该完全跳过这一层。
yeotifhr2#
如果您的控制器不需要业务逻辑或执行单个存储库操作，则可以直接使用存储库。使用服务来实现需要业务逻辑或存储库调用编排的用例。
r7s23pms3#
如果它是一个分层的CRUD应用程序，我认为只要应用程序简单、小，控制器就可以了解存储库并直接调用它进行简单的读取操作
权衡：
与
controller -> repository -> persistence相反，controller -> service -> repository -> persistence的结构并不是一条硬性规则。您的用例似乎适合后者。zfycwa2u4#
在我看来，服务层必须实现业务逻辑，并且必须从控制器调用它。在大多数情况下，该层必须执行更多的操作，而不仅仅是从DAO对象调用方法。如果您的应用程序规模很大，这可能是最好的解决方案。此外，您可以将逻辑分成几个部分，并使其在一个事务中工作，这有助于将数据保存在非争议状态。
wmomyfyw5#
一种方法是为DB中规范化实体的视图和存储库上显示的业务级概念保留控制器。然后可以定义服务来解决控制器和存储库之间的多对多关系。
y4ekin9u6#
如果您不需要事务，并且不涉及业务逻辑，那么就不需要额外的代码。
spring文档中有控制器调用repo时的示例。此处的示例51https://docs.spring.io/spring-data/data-commons/docs/current-SNAPSHOT/reference/html/#reference例如
myzjeezk7#
首先，您不应该在控制器类中同时使用服务和repo类。以下是使用SpringBoot时的一些良好实践：
1.回购类应注入服务类
1.必须在Controller类中注入服务类
遵循这一点，你可以有效地使用它。在控制器中同时使用服务和repo对象就像混淆要调用哪个示例的spring上下文。
kmbjn2e38#
如果使用的是spring boot，正确的注解是
@Autowired，而不是@Inject。