我开始使用 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(...);
}
最好的做法是这样做还是让服务返回 ResponseEntity？我是 Spring MVC 的新手。我阅读了一些关于 Stackoverflow 的文章，其中一些解释了一般设置。但是我找不到如何处理例如 ResponseEntity。
我认为您可以争辩说 ResponseEntity 也应该在服务中，因为您可能需要返回不允许的方法或类似的东西，并确定是否返回不允许的方法 ResponseEntity 或 OK 实体可以被视为业务逻辑的一部分。但我不知道。
谢谢!
最佳答案
Short Answer
是的，Service返回域对象应该优于 Service返回 ResponseEntity<> .
Long Answer
没有 best practices .话虽如此，您应该考虑实现类似六角形或分层架构的东西。在六边形架构中，应用程序/域逻辑被限制在应用程序/域层中，该层与表示层、持久性/基础设施层分开。接口(interface)在应用层(称为端口)中定义，实现在基础设施层(称为适配器)中提供。有一个 excelled article on this .
类似 Service 的概念, Repository取自 DDD .要了解有关 DDD 的更多信息，您可以查看 Vaughn Vernon 的书 Implementing Domain-Driven Design .
关于java - Spring MVC——逻辑RestController和Service的分离，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/63544072/