Spring MVC - 分离逻辑 RestController 和 Service

Question

我开始使用Spring MVC构建我的第一个REST API :) 现在我遇到了一些困难，不知道将哪种逻辑放在哪里。我阅读了以下内容： @RestController: 处理请求，定义了用户可以使用的API @Service: 包含业务逻辑 @Repository: 抽象化了对DB的访问

在一个简单的例子中，我看到流程是这样的：RestController 调用 Service，Service 调用 Repository。在第一步中，我就这样做了。

现在我想使用 ResponseEntity - 我听说使用它是很好的做法。但现在我开始想：服务层应该返回 ResponseEntity 还是领域模型的实例？

为了说明我的意思（是的，我是个大足球迷）：

@GetMapping("/clubs")
public ResponseEntity<List<FootballClub>> getAllClubs(@RequestParam String footballLeague) {
    List<FootballClub> clubs = service.getAllClubs(footballLeague);
    return new ResponseEntity(...);
}

这样做是最佳实践，还是让Service返回ResponseEntity更好？我刚接触Spring MVC。我在Stackoverflow上阅读了一些文章，其中有一些解释了常规设置。但是我无法找到如何处理例如ResponseEntity的信息。

我认为你可以争论说ResponseEntity也应该在Service中，因为你可能需要返回方法不允许或类似这样的东西，确定是返回方法不允许的ResponseEntity还是OK实体可以被视为业务逻辑的一部分。但我不确定。

谢谢！

- KarlMeierBE

Answer 1

简短回答

是的，返回领域对象的Service应该比返回ResponseEntity<>的Service更可取。

详细回答

没有最佳实践。话虽如此，您应该考虑实现类似六边形或分层架构的东西。在六边形架构中，应用程序/领域逻辑被限制在应用程序/领域层中，该层与表示层、持久性/基础设施层分离。接口在应用程序层中定义（称为端口），并在基础设施层中提供实现（称为适配器）。这里有一篇优秀的文章。

像Service、Repository这样的概念来自于DDD。要了解更多关于DDD的内容，您可以查看Vaughn Vernon的书实现领域驱动设计。

- Pankaj

Answer 2

该服务应返回领域模型的实例。ResponseEntity（与控制器在请求处理后返回的响应相关）应在控制器级别创建。

- Massimo Petrus