MVC 는 Model, View, Controller의 약자 입니다. 하나의 애플리케이션, 프로젝트를 구성할 때 그 구성요소를 세가지의 역할로 구분한 패턴입니다. MVC패턴은 소프트웨어 개발에서 사용되는 디자인 패턴 중 하나로, 애플리케이션의 구성 요소를 분리하여 유지보수성, 확장성, 코드 재사용성을 향상시키는 데 도움을 줍니다. 주로 웹 및 데스크톱 애플리케이션을 개발하는 데 적용되며, 사용자 인터페이스를 관리하는 데 특히 효과적입니다.
Node.js는 자유도가 매우 높기 때문에, Controller나 Service가 따로 분리되어 있지 않습니다. 이에 MVC 패턴을 적용하여 서비스의 구성 요소를 분리하고 확장성을 높였습니다.
Model
- Model은 애플리케이션의 데이터와 비즈니스 로직을 포함하는 부분입니다.
- 데이터의 상태와 조작을 관리하며, 데이터베이스에서 데이터를 가져오거나 저장하는 등의 작업을 수행합니다.
- 데이터가 어떻게 구성되고 조작되어야 하는지에 대한 규칙을 정의하며, 데이터의 변경 사항을 모니터링하여 View와 Controller에게 알립니다.
- Model은 일반적으로 데이터의 무결성을 유지하고 업데이트하는 책임을 가집니다.
- 뷰나 컨트롤러에 대해서 어떤 정보도 알지 말아야 한다. 이는 데이터 변경이 일어났을 때 모델에서 화면 UI를 직접 조정해서 수정할 수 있도록 뷰를 참조하는 내부 속성값을 가지면 안 된다는 말입니다.
View
- View는 사용자 인터페이스를 나타내며, 데이터의 시각적 표현을 담당합니다.
- 모델의 데이터를 사용자가 이해하고 상호 작용할 수 있는 형태로 표시합니다.
- View는 일반적으로 사용자에게 정보를 보여주고 사용자 입력을 받는 역할을 합니다.
- Model의 데이터 변경을 감지하고, 변경된 데이터를 화면에 반영하기 위해 업데이트됩니다.
- 모델이 가지고 있는 정보를 따로 저장해서는 안된다.
- 모델이나 컨트롤러와 같이 다른 구성요소들을 몰라야 된다. 이는 데이터 변경이 일어났을 때 모델에서 화면 UI를 직접 조정해서 수정할 수 있도록 뷰를 참조하는 내부 속성값을 가지면 안 된다는 말입니다.
Controller
- Controller는 사용자 입력을 처리하고 Model과 View 사이의 중개자 역할을 합니다.
- 사용자가 애플리케이션과 상호 작용할 때, Controller는 해당 이벤트를 감지하고 Model을 업데이트하거나 View를 변경하는 작업을 수행합니다.
- Controller는 비즈니스 로직을 구현하며, 사용자의 요청에 따라 Model과 View 사이의 흐름을 제어합니다.
- 여러 개의 View와 연결되어 동일한 Model을 공유할 수 있습니다.
- 모델이나 뷰에 대해서 알고 있어야 한다. 모델이나 뷰는 서로의 존재를 모르고, 변경을 외부로 알리고, 수신하는 방법만 가지고 있는데 이를 컨트롤러가 중재하기 위해 모델과 그에 관련된 뷰에 대해서 알고 있어야 합니다.
우리 서비스의 구조
- Client → Controller
우리의 서비스는 클라이언트에서 온 정보를 validator로 검사하여 controller로 보냅니다.
- Controller → Service
controller는 다시 service로 해당 정보를 보내고, service는 요청에 맞게 Database에서 정보를 조회하거나 저장합니다.
- Database → Service
데이터베이스에서 온 정보는 controller가 알 필요가 없는 불필요한 정보를 converter를 통해 제거하고
- Controller → Client
다시 controller는 responseDto로 감싸서 클라이언트에게 필요한 정보만을 보내줍니다.
왜 사용해야하는가?
일단 제가 프로젝트를 진행하며 MVC패턴을 사용한 결과 느낄 수 있는 이점이 몇가지 있었습니다.
로직이 깔끔해진다
예전에 Controller에 모든 코드를 집어 넣는 방식보다 Controller와 Service를 분리하여 사용하니 코드 가독성은 물론 특정 부분만을 수정하기 훨씬 편해졌습니다.
코드 재사용성이 늘어난다
이건 1번과도 이어지는 내용인데, 서비스에서 겹치는 부분 예를 들면 유저 조회 같은 함수를 만들어 두면 어느곳에서나 가져다 쓸 수 있어 재사용성이 늘어나고, 이 또한 유저 조회를 수정할때 한 부분만 수정하면 되어서 편리해졌습니다.
확장성이 늘어났다
프로젝트를 진행하며 역 정규화를 위해 특정 모델에 특정 column를 추가하거나, front 개발자들의 요청에 의해 응답값에 특정 데이터를 추가할 일이 많았습니다. 이때 converter나 Dto의 특정 부분만 수정하면 되었기 때문에 해당 모델을 사용하는 전체 서비스를 수정하지 않고 손쉽게 응답 객체를 수정할 수 있게 되었습니다.
