이번 포스팅에서는 예고한 대로 추가적으로 레이어드 패턴이 처리 되는 과정 중심으로 기술할 예정이다. 먼저, 이렇게 우리가 mvc를 쓰는 것의 장점부터 알아보자.
01. mvc 패턴의 장점
- 염려의 분리 (Seperation of Concerns)
유저 인터페이스와 관련된 부분은 모두 View 에 의해서 관리되고, 모든 데이터와 관련된 로직은 Model 에 의해서 관리되며 오로지 Controller 에 의해서 Model 에 접근할 수 있게 된다. 각각의 레이어가 하는 역할이 명확 하다.- 동시적인 개발 (Simultaneous Development)
세개의 레이어로 역할이 나뉘어져 있기 때문에 동시다발적인 개발이 가능하다. 역할분담에 용이하며 협업이 가능한 프로젝트를 구성할 수 있다.- 수정의 용이함 (Ease of Modification)
다른 레이어에 영향을 주지 않고 문제가 있는 로직을 찾아서 문제를 해결할 수 있다.- 테스트-주도 개발(Test Driven Development)
각각의 레이어, 그리고 그 레이어 속에 속한 각각의 모듈을 테스트 하기 좋다.
02. 노드 js에서 레이어드 패턴의 활용
물론 vmc 패턴이 기본적이지만, 일반적으로 그렇게 모델과 컨트롤러만 사용할 경우, 하지만 오로지 이 두개의 레이어로만 로직을 분리하기에는 코드의 복잡성과 레이어 하나가 담당하는 비중이 너무 커지기 때문에 더 확장해서 프로젝트 코드를 레이어링 해야 한다.
그래서 조금 더 나눠본 결과는 다음과 같다.
즉, 컨트롤러 위에 기존 리엑트에서 보던 라우터 기능을 해주는 라우트모델이 큰 전체 라우팅 설정을 하는 터미널 역할을 한다. 그리고 그 밑에 컨트롤러, 서비스, 모델 순이다. 여기서 추가된 서비스는 기본적으로 해당 서비스와 관련된 처리 기능을 담은 것인데, 주로 인증, 인가, 보안 처리 등이 이루어진다.
프로세스를 정리하면,
- 큰 박스에서 작은 박스로 갈 수록 더 데이터를 다루는 로직(데이터베이스 접근하는 로직)에 근접하게 된다.
- 또한, 각각의 레이어는 오로지 바로 아래에 있는 레이어에만 의존하게 된다.
- Route → Controller
- Controller → Service
- Service → Model
예를들어, Route 는 Service 로직을 전혀 모른다. 아예 관여 조차 하지 않습니다.
따라서, Service 로직을 변경해도 Route 와 Controller 의 코드는 바뀔 필요가 없다.
즉 다음과 같은 상황에서 유연하게 대처할 수 있다는 의미다.
때때로, 서비스를 구현하다가 RDBMS(관계형 데이터 베이스) → NoSQL(ex. mongoDB) 로 이전하는 경우가 있는데, Route와 Controller 의 로직은 전혀 바뀌지 않은채로 데이터를 다루는 Service 와 Model 의 로직만 변경 해 주면 된다.
위에서 아래로 갈수록 데이터베이스 접근에 근접하게 되며, 핵심 로직을 다룬다고 할 수 있다.
03. 서비스 프로세싱 정리 표.
이것으로 기본적인 레이어드 패턴에 대한 기본적인 이론정리는 되었다. 다만, 실전 적용 시에 어떻게 되는 지에 대해서 궁금할 수 있다. 이 부분은 필자가 향후 진실의 방 포스팅에 남기겠다.
