글의 목적
Spring Framework의 controller,repository,service 클래스를 만들어서 각각의 역할에 맞게 개발을 진행했다. 각 층별로 하는 역할이 무엇인지 그리고 왜 Layer를 나누어야 하는지에 대해 조사한 것을 기록해보자
Layer(계층)
- Spring Layerd architecture의 구조로 검색하면 이와 비슷한 이미지들을 보여준다.
왜 Layer라는 것들로 나누어서 관리하는지에 대해 알아보자
Layer는 관심사의 집합이다. 따로 각각의 집합이라고 표현하지 않고 Layer라고 표현하며 계층관계를 나타내는 것은 , 상위 Layer에서 하위Layer로만 컨트롤 할 수 있기 때문이다.
구체적인 예시를 들면, PresentLayer에 있는 Controller는 Service의 인터페이스를 조작하여 데이터를 전달 받을 수 있지만 Service는 Controller를 조작하는 코드를 작성하면 안된다.
또한 관심사의 집합이라 표현한 이유는 관심사 주제별로 층을 많이 나누면 구조가 복잡해지기 때문에 관심사를 묶어 계층으로 나타냈다.
Layer 생성에는 두가지 원칙이 존재한다.
1. 소프트웨어를 만들 때, 관심사를 명확히 알고 Layer에 관심사를 정해줄 것 ( Layer의 책임역할 이 분명해진다.)
2. 분리하되, 너무 많은 Layer를 생성하지 말것.Spring web Application
위의 계층을 나누는 원칙을 생각하여, Spring MVC 관점으로 관심사를 나누어 보자
- 사용자에게 요청을 받으면, 그에 맞는 반응 해줄 것
- 사용자 요청 중 exception에 대해 처리해줄 것
- transcation 처리해줄 것
- 인증 및 권한 부여해줄 것
- 비지니스 로직을 구현해줄 것
- 외부 Resource 및 내부 데이터 저장소와 통신할 것
이렇게 관심사가 나누어지고 spring 에서는 보편적으로 3개의 Layer로 분리해서 사용한다
Presentational Layer - Service Layer - Repository Layer
Presentational Layer
책임(역할)
- 사용자 요청을 받으면 그에 맞는 반응
- 사용자 요청 중 exception 처리
구현
- 사용자에게 view 노출 시킨다.
- 사용자는 특정 요청을 합니다. 이 때, dispatcher servlet이 컨트롤러로써 요청을 받습니다. 또는 이 요청이 잘못된 경우 exception 처리를 해준다
- dispathcer servlet은 관리인으로써 역할만을 갖고 있다. 요청에 맞는 데이터를 처리하기위해선 개발자가 Controller를 따로 작성하도록 하였습니다.
- 따라서 dispatcher servlet은 사용자 요청을 받은 후 해당 요청에 적절한 컨트롤러에게 처리하도록 전달해준다.
- 요청을 받은 컨트롤러는 적절한 output이 view에 그려지도록 view에 적절한 데이터를 하위 레이어에 요청하고 전달해준다.
- controller는 데이터 모델을 전달할 책임만 있을 뿐 접근할 책임이 없기 때문에 하위 레이어에게 데이터 접근을 요청하게 된다.
Service Layer
책임(역할)
- 비지니스 로직을 구현합니다.
- transaction 처리를 합니다.
*cf) 비지니스 로직이란? = 업무처리에 대한 로직이다
예를들어 쇼핑몰 사이트의 view(웹페이지) 를 통해 주문이라는 행동을 요청하게 되면, 우리는 업무처리에 대한 로직을 실행해서 주문에 맞는 행동을 서버에서 진행해야한다. 이 때, 주문에 해당하는 로직들을 service layer에서 수행한다고 생각하면 좋을거 같다.
구현
- Service 객체에서 비즈니스 로직을 수행하는 코드를 작성합니다. 단 DB에 직접적인 접근은 하지 않는다. 데이터를 조작하는 역할은 하위 레이어에게 맡깁니다.
- 특정 비지니스 로직을 수행하기 위해 데이터를 조작하는 일을 수행하나, 이 조작하는 일이 하나의 단위로 수행되어야 할 때, service에서 @transactional annotation을 통해 관리를 하게 됩니다.
Repository Layer
책임(역할)
- 내부 데이터 저장소에 접근한다.
구현
- Dao(Data Access Object)를 만들어서 접근하게 된다.
이렇게 층별로 관심사가 나뉘어 진다. 또한 3개의 레이어로 나눈 이유 중 하나는 재사용성에 있다.
3-Layer 재사용성
만약 쇼핑 페이지에서 사용자의 요청이 웹페이지가 아닌 윈도우 어플리케이션에서 요청하는 것으로 바뀌었다. 그렇다고 가정하면, 사용자의 요청에 따른 비지니스 로직이 바뀔까? 혹은 DB가 바뀔까?
Presentationa layer가 바뀌었다 하여 service layer, repository layer가 바뀌진 않는다.
service layer를 기준으로 쉽게 때어낼 수 있또록 presentational layer 에 대한 설정과 repository layer, service layer의 설정을 분리한다.
그래서 service Layer를 기준으로 controller 간 의존성을 낮추기 위해 service interface를 작성한다.
Reference
https://www.petrikainulainen.net/software-development/design/understanding-spring-web-application-architecture-the-classic-way/
https://jurogrammer.tistory.com/78
