Spring MVC – 将逻辑分离为 RestController 和 Service

huangapple go评论64阅读模式
英文:

Spring MVC - Separation of logic RestController and Service

问题

我开始使用Spring MVC来构建我的第一个REST API Spring MVC – 将逻辑分离为 RestController 和 Service 现在我在一些逻辑放在哪里方面遇到了一些困难。我阅读了以下内容:

@RestController:处理请求,定义用户可以使用的API
@Service:包含业务逻辑
@Repository:抽象了对数据库的访问

在一个简单的第一个示例中,我看到流程是这样的:RestController调用Service,Service调用Repository。在第一步中,我是这样做的。

现在我想使用ResponseEntity - 我听说这是一个好习惯。但现在我开始疑惑:Service层应该返回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的实体,这被认为是业务逻辑的一部分。但我不太清楚。

谢谢!

英文:

I started using Spring MVC to build my first REST API Spring MVC – 将逻辑分离为 RestController 和 Service Now I struggle a bit of where to put which logic. I read the following:
@RestController: Handles requests, defines the API the user can use
@Service: Contains the business logic
@Repository: Abstracts away from access to DB

In an easy first example, I saw the flow was like this: RestController calls Service, Service calls Repository. In the first step, I did it like this.

Now I want to use ResponseEntity - I hear it is good practice to use that. But now I start wondering: Should the service layer return ResponseEntity or just the instances of the domain model?

To show what I mean (yes, I am a big football fan):

@GetMapping(&quot;/clubs&quot;)
public ResponseEntity&lt;List&lt;FootballClub&gt;&gt; getAllClubs(@RequestParam String footballLeague) {
    List&lt;FootballClub&gt; clubs = service.getAllClubs(footballLeague);
    return new ResponseEntity(...);
}

Is it best practice to do it like this or to let the Service return the ResponseEntity? I am new to Spring MVC. I read some articles on Stackoverflow and some explain the general setup. But I could not find how to deal with for instance ResponseEntity.

I think you can argue that ResponseEntity should also be in Service as you might need to return method not allowed or something like this and determining whether to return a method not allowed ResponseEntity or an OK Entity could be considered part of the business logic. But I don't know.

Thank you!

答案1

得分: 2

> Short Answer

是的,应该更倾向于返回领域对象的 Service,而不是返回 ResponseEntity&lt;&gt;Service

> Long Answer

并没有固定的最佳实践。尽管如此,你应该考虑实现类似于六边形架构或分层架构的方式。在六边形架构中,应用程序/领域逻辑被限制在应用程序/领域层中,与表示层、持久化/基础设施层分开。在应用程序层中定义接口(称为端口),在基础设施层提供实现(称为适配器)。这方面有一篇优秀的文章进行了阐述。

诸如 ServiceRepository 的概念来自于领域驱动设计(DDD)。想要了解更多关于DDD的信息,可以查阅 Vaughn Vernon 的书籍 实现领域驱动设计

英文:

> Short Answer

Yes, Service returning domain object should be preferable to a Service returning ResponseEntity&lt;&gt;.

> Long Answer

There is no best practices. Having said that, you should think of implementing something like Hexagonal or Layered architecture. In Hexagonal architecture, application/domain logic is confined in application/domain layer which is separated from presentation, persistence/infrastructure layer. Interfaces are defined in application layers (called ports) and implementation is provided in infrastructure layer (called adapters). There is an excelled article on this.

Concepts like Service, Repository is taken from DDD. To know more about DDD you can check Vaughn Vernon book Implementing Domain-Driven Design.

答案2

得分: 1

这项服务应该返回领域模型的实例。ResponseEntity(与控制器在请求处理后返回的响应相关)应该在控制器层级创建。

英文:

The service should returns instances of the domain model. The ResponseEntity (which is related to the Response the controller returns after request elaboration) should be created at controller level.

huangapple
  • 本文由 发表于 2020年8月23日 14:30:29
  • 转载请务必保留本文链接:https://go.coder-hub.com/63544072.html
匿名

发表评论

匿名网友

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen:

确定