처음에 든 의문점은 기존의 MVC의 Controller에서 Service로 왜 또 분리하였는가? repository는 무엇인가? 였다.

📌첫번째 의문점

기존의 MVC의 Controller에서 Service로 왜 또 분리하였는가?
첫번째 의문점을 해결하기 위해서는 Controller와 Service의 차이점부터 명확히 알아야 했다

📖 Controller vs Service

Controller

• 클라이언트의 요청을 받음
• 요청에 대한 처리는 서비스에게 전담
• 클라이언트에게 어떻게 응답할지 결정하는 곳
• 클라이언트에게 처리값으로 응답하는 곳
• 클라이언트가 이용할 End Point

Service

• 사용자의 요구사항 처리
• DB 정보가 필요할 때는 Repository에게 전담

즉, Model → Service → Controller → View 의 로직이 발생하는 것
음.. 좀더 Controller와 Service에 대한 역활이 명확하게 나눠서 지지않은 나를 이해시키기 위해 추가 설명을 더 해보자면,😱

1. 회원가입 페이지에서(View) 회원가입 데이터를 작성하고 회원가입을 해달라고 요청을 합니다.
2. Controller에서는 해당 요청을 받고, ‘이건 회원가입 요청이구나’ 판단을 하게 되죠 그럼 회원가입을 할때 '해야할 것'이 있는 Service를 호출하게 됩니다.
3. Service에서는 아이디, 비번 등의 데이터를 체크해야하고 DB와 통신와 통신하면서 회원가입을 할때 해야 할 작업을 수행 합니다. (데이터 가공)
   → 해야 할 일 = 비지니스 로직
4. 작업이 끝난 Service는 이제 다시 Controller에 값을 주고
5. Conroller는 받은 값으로 클라이언트에게 응답을 하게 됩니다.

질문 많은 나의 뇌는 질문을 다시 막 던진다. ‘

Q. 기존의 Controller에서 그냥 비지니스 로직까지 다 하면 안되는 건가? 분리하는게 더 복잡한 거 아니예요??’

A . 만약 상품 페이지에서 클라이언트가 한 상품에 대해 찜하기 요청을 했어요. 그럼 위의 순서대로 한다면, controller는 판단하고 service는 찜하기 행동을 위한 어떠한 비지니스 로직들을 하겠죠? 예를 들면, 이전에 찜을 해놓은 상품인지 확인해서, 이전에 찜해놓은 기록이 있는데도 다시 클릭한것이니 찜을 다시 취소하고, 처음 찜한거면 디비에도 반영해야 하고 등등 많은 일들이 있죠.
근데 만약 " Serive를 만드는 과정이 너무 귀찮아서 Service 없이 Controller에서 이것들을 그냥 다 처리하게 하려고 한다면?"
처음에는 문제 없을 것인데 상품 페이지 말고도 인기상품페이지, 행사목록페이지 등 다양한 조건의 페이지가 다시 등장하면 찜하기 행동의 비지니스 로직들을 컨트롤러 속의 매페이지마다 똑같이 다 써줘야 하는 더 엄청난 귀찮음이 생겨요. 한번 수정하려면 일일히 다 찾아서 다 수정해야 하고요. 그냥 코드를 재활용하고, 수정도 한번에 쫙 하는게 낫지 않을까요?

즉, 코드의 재사용성(중복 코드 방지), 유지보수 용이의 이유로 분리하는 것이다

📌두번째 의문점

repository는 무엇인가?

📖Repository

• DB 관리(연결, 해제, 자원 관리)
• DB CRUD 작업 처리

즉 , Repository → Service → Controller → View 의 로직이 생성된다. MVC 패턴에서 Model과 Repository는 유사하다.