서비스 계층이 필요한 이유는 무엇입니까?

서비스 계층이 필요한 이유는 무엇입니까?

저는 현재 스프링 부트를 배우고 있으며 사람들이 컨트롤러를 만들고, 서비스 클래스를 주입하고, 서비스 클래스에서 저장소를 주입하는 방법을 보았습니다.

중간 관리자로서 서비스 클래스가 필요한 이유는 무엇이며, 컨트롤러에 저장소를 주입할 수 없는 이유는 무엇입니까?

여기 저를 혼란스럽게 했던 튜토리얼이 있습니다: https://www.youtube.com/watch?v=lpcOSXWPXTk&list=PLqq-6Pq4lTTbx8p2oCgcAQGQyqN8XeA1x

항상 서비스 계층이 필요한 것은 아닙니다.특히 API가 실제 논리나 계산이 필요 없는 단순한 CRUD 작업일 경우에는 더욱 그렇습니다.

그러나 저장소를 쿼리하기 전에 일부 논리를 수행하는 API가 있다면 별도의 서비스 클래스에 있어야 합니다.이것은 단일 책임 원칙으로 알려진 것에서 발생하는 좋은 관행입니다.

https://en.wikipedia.org/wiki/Single_responsibility_principle

• 컨트롤러는 수신 요청을 처리해야 합니다.
• 서비스 계층의 유일한 책임은 컨트롤러가 수신하는 데이터에 필요한 모든 논리를 수행하는 것입니다.
• 저장소의 유일한 책임은 데이터베이스를 쿼리하는 것입니다.

계층화된 아키텍처는 일반적으로 다음과 같은 이유로 지원됩니다.

계층을 사용하여 기본 구현을 추상화할 수 있으므로 쉽게 변경할 수 있습니다.

계층화의 행복한 부작용은 - 충실하게 지켜진다면 - (a) 인터페이스를 사용하여 각 계층을 정의하고 (b) 우려 사항을 분리하도록 장려함으로써 시스템을 테스트 가능성을 높일 수 있다는 것입니다.

그래서 그것이 원칙이지만 (적어도) 다른 원칙처럼 오해되고 잘못 적용될 수 있습니다.

대부분의 경우 보기 계층에서 데이터 액세스를 숨기기 위한 계층화의 이점은 확실하지만, 보기 계층과 데이터 계층 사이에 서비스 계층을 포함하는 이점이 항상 그렇게 매력적인 것은 아닙니다.다음을 포함하는 시스템...

• 소수의 컨트롤러
• 적은 수의 리포지토리
• 컨트롤러와 리포지토리 간의 1:1 매핑
• 도메인 표현(리포지토리)과 보기 표현(컨트롤러) 간에 복잡한 변환이 필요하지 않음

아마 서비스 계층이 필요하지 않을 것입니다.

반면에, 시스템은...

• 많은 수의 컨트롤러 및 리포지토리
• 컨트롤러와 리포지토리 간의 복잡한 관계(예: 컨트롤러가 여러 리포지토리를 사용하여 결과를 결합하거나 이러한 리포지토리를 체인으로 호출)
• 도메인 표현(리포지토리)과 보기 표현(컨트롤러) 간의 복잡한 변환

아마 서비스 계층이 필요할 것입니다.

이는 서비스 기능을 전송에서 분리하는 방법이며, 서비스는 단일 책임(SOLID)을 포함하고 HTTP/REST 또는 AMQP와 같은 서로 다른 포트(육각형 아키텍처)를 사용하여 노출할 수 있는 기능을 정의합니다.

서비스 계층을 추가하면 나중에 포트를 변경하거나 둘 이상을 사용할 수 있습니다.

이와 같이 Rest Controller 레이어에 많은 코드를 넣을 필요가 없으며, 이는 깨끗해야 하며 통신과 관련된 코드로만 이루어져야 합니다.

따라서 모든 논리 및 IF 등은 컨트롤러 계층에 유지되어야 합니다.

리포지토리 계층은 인터페이스 방식을 고수해야 합니다. 이 방식은 메소드 내부에 코드를 포함하지 않고 데이터를 얻는 방법의 레이아웃만 포함하고 논리는 포함하지 않아야 합니다.

Spring 부트 컨트롤러는 외부와의 인터페이스로, 예를 들어 UI와 크게 다르지 않습니다.두 개 이상의 UI 맛을 원하는 것처럼 비즈니스 로직에 대한 두 개 이상의 인터페이스를 가질 수 있습니다.특히 당신이 그것이 오래 지속되고 미래의 API 프레임워크에 적응하기를 원한다면 더욱 그렇습니다.만약 당신의 논리가 컨트롤러에 내장되어 있다면, 당신은 그 지점에 도착했을 때 꽤 많은 리팩터링을 해야 합니다.

따라서 논리의 복잡성에 따라 별도의 컨트롤러가 필요합니다.

언급URL : https://stackoverflow.com/questions/46442790/why-do-we-need-service-layer