MVC pattern
MVC 패턴은 Model, View, Controller를 뜻하는 세 가지의 개발 영역을 구분하여 클라이언트의 요청을 처리하고 REST, text, html 등 다양한 형태의 응답을 할 수 있는 개발 방법론 중 하나이다. 영역 구분으로 인해 각 요소들이 서로에게 미치는 영향을 최소화하면서 개발할 수 있고 유지보수를 쉽게 만들어준다.
Model
Application 안의 모든 데이터에 대한 인터페이스, logical structure
해석에 따라 비즈니스 로직, Service 계층이 아닌 데이터 객체 그 자체만을 가리키는 경우도 있는 것 같다.
- 사용자가 편집하길 원하는 모든 데이터를 가지고 있어야한다.
- 뷰나 컨트롤러에 대해 어떤 정보도 알지 말아야한다.
- 변경이 일어나면 변경 통지에 대한 처리 방법을 구현해야한다.
View
사용자 인터페이스 요소
데이터의 입력과 출력 부분을 담당한다.
- 모델이 가지고 있는 정보를 따로 저장해서는 안된다.
- 모델이나 컨트롤러와 같이 다른 구성 요소들을 몰라야한다.
- 변경이 일어나면 변경통지에 대한 처리 방법을 구현해야한다.
Controller
데이터와 인터페이스를 이어주는 다리 역할
이벤트 처리 역할
- 모델이나 뷰에 대해 알고있어야한다.
- 모델이나 뷰의 변경을 모니터링해야한다.
알아보다 헷갈렸던 점
Model과 View의 정의
설명하는 사람에 따라 Model을 데이터를 담고 있는 객체만을 뜻하는 경우도 있고 데이터를 다루는 service layer나 business logic 모두를 뜻하는 경우도 있었다.
특히 View의 경우 JSP나 Django의 template(Django에서는 MVT 패턴이라 부르긴 하지만) 과 같이 html 형식으로 렌더링해서 주는 방식만을 view라고 하는 사람도 있고 어떤 형태로든 클라이언트가 이해할 수 있는 형태(json, xml, html 등)으로 준다면 view라고 하는 사람도 있었다. 전자의 경우일 때 궁금했던 점이 Rest API와 같이 JSON을 응답으로 주는 API는 MVC 구조가 아닌가? 였다. 여기와 같이 의견이 다양했다.
최종적으로는 여기의 답변을 보고 정리할 수 있게 되었던 것 같다. 처음에 말했듯이 MVC 패턴은 개발 방법론 중 하나일 뿐이고 서버단의 코드 구조화가 핵심이다. Model이 객체를 뜻하는지 로직을 뜻하는지, View가 html을 반환하든지 json을 반환하든지 하는 정의는 크게 중요하지 않은 것 같다. 각 영역을 나누어 개발하고 유지보수를 쉽게 만드는 것이 MVC 패턴의 의미이다. 이런 맥락에서 굳이 정의를 하자면 더 범위가 크고 보편적인 정의를 따르는 것이 맞다고 생각한다.
Spring(RESTful API)을 예시로 들면
Model: service layer, entity, dao 등등
Controller: controller layer
View: json serialize
정도로 정리할 수 있을 것 같다.