Question

我使用Spring Boot和Spring Data。

我认为分离存储库层和服务层

没有问题

所以我有一个带有CRUD方法的UserRepository和一些Spring Data方法

的findAll
findByUsername

我也有UserService和业务方法。

checkPassword（String login，String password）
businessMethodAction（String username）

这是我的问题：

在我的控制器中，我必须从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);
}

你有什么看法？

Answer 1

控制器层不应该直接调用存储库。您应该始终使用服务层，因为服务层封装了围绕该调用的业务逻辑。仅仅因为目前不是任何业务逻辑，并不意味着您应该完全跳过该层。

Answer 2

在我看来，服务层必须实现业务逻辑，并且必须从控制器调用它。在大多数情况下，除了从DAO对象调用方法之外，该层必须执行更多操作。如果您的应用程序具有很大的尺寸，这可能是最佳解决方案此外，您可以将逻辑分成几个部分并使其在一个事务中工作，这有助于您将数据保存在无争议状态。

Answer 3

如果控制器不需要业务逻辑或执行单个存储库操作，则可以直接使用存储库。使用服务来实现需要业务逻辑或编排存储库调用的用例。

Answer 4

如果您使用的是Spring Boot，则正确的注释应该是C:\Program Files\，而不是@Autowired。

Answer 5

如果它是分层的CRUD应用程序，那么我认为控制器知道存储库并直接调用它以进行简单的读取操作就可以了，只要该应用程序简单，小

权衡：

调用回购协议的控制器删除了服务层的抽象层
控制器和存储库现在已耦合
如果您的阅读操作没有要求/用例/业务逻辑，则建议不要提供全面的服务。 YAGNI（您将不需要它）。意思是，鉴于业务需要，在此时实施额外的“直通”服务层没有任何意义。
在选择让控制器了解您的存储库之前，建议您考虑是否已将存储库层与持久性层分离。

与controller -> service -> repository -> persistence相比，controller -> repository -> persistence的结构不是一成不变的规则。您的用例似乎适合后者。

Answer 6

一种方法是为数据库中标准化实体的视图和存储库上显示的业务级别概念保留控制器。然后，可以定义服务来解决控制器和存储库之间的多对多关系。

使用Spring从控制器层调用存储库和服务

6 个答案: