Spring MVC-逻辑RestController和服务的分离

2020年8月24日 86点热度 0条评论

我开始使用Spring MVC构建我的第一个REST API :)现在,我在将哪种逻辑放在何处感到困难。我阅读以下内容:@RestController:处理请求,定义用户可以使用的API@Service:包含业务逻辑@Repository:远离访问数据库的摘要
在第一个简单的示例中,我看到流程是这样的:RestController调用Service,Service调用存储库。第一步,我是这样做的。
现在,我想使用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实体可以视为业务逻辑的一部分。但是我不知道。

谢谢!

解决方案如下:

简短答案

是的,返回Service的域对象应该比返回ServiceResponseEntity<>更好。

详细答案

没有best practices。话虽如此,您应该考虑实现类似六角或分层体系结构的东西。在六边形体系结构中,应用程序/域逻辑被限制在与表示,持久性/基础结构层分离的应用程序/域层中。接口在应用程序层(称为端口)中定义,实现在基础结构层(称为适配器)中提供。有一个excelled article on this
ServiceRepository这样的概念都来自DDD。要了解有关DDD的更多信息,可以查看Vaughn Vernon的Implementing Domain-Driven Design书。