MVC 패턴

전우재·2024년 2월 10일

Study

목록 보기

2/4

Model
- Model은 데이터와 그 데이터를 처리하는 로직을 담당한다.
- 예를 들어, 사용자에게 입력 받은 정보를 데이터베이스에 저장하거나, 데이터베이스에서 정보를 가져와 보여주는 역할을 한다.
View
- View는 사용자 인터페이스를 담당한다.
- 사용자가 보는 화면을 생성하고, 사용자로부터의 입력을 Controller에 전달하는 역할을 한다.
Controller
- Controller는 Model과 View를 연결하는 역할을 한다.
- 사용자로부터의 입력을 Model로 전달하고 Model의 데이터를 View로 전달하여 사용자에게 보여주는 역할을 한다.
이렇게 MVC 패턴은 애플리케이션의 로직을 Model,View,Controller로 분리하여 각 구성 요소가 자신의 역할에 집중할 수 있도록 한다. 이로써 코드의 명확성이 높아지고 유지 보수가 용이해진다.

Smalltalk의 mvc

해당 자료는 Smalltalk에서 1988년에 작성한 문서에서 mvc 패턴.
view가 model을 알고 있어서 해당 정보로 화면을 구성하고 있음.
해당 자료는 cocoa에서 작성한 mvc 패턴.
view가 model을 알 수 없기 때문에 모든 작업을 controller가 처리.

둘 다 spring에서 사용하는 mvc와는 다르다.
보통 spring에서 사용하는 mvc는 JSP를 사용한 model2 MVC.
앞에 고민했던 여러 패턴들을 cocoa가 주장한 mvc 패턴에서 컨트롤러의 책임을 줄이기 위해 나온 패턴들이었다.
심지어 안드로이드에서의 MVC도 다르게 정의하기도 했다....

각자의 방식대로 정의된 MVC 패턴들에서 중요한 것이 있다면 바로 관심사 분리라고 생각하게 되었다.
각각의 환경(spring, cocoa, android, smalltalk)에서 MVC 패턴이 조금씩 다르게 구현될 수 있지만, 이 차이는 환경의 특성과 요구 사항에 따라 정의한 결과물이라고 생각했다.
예를 들어, Spring MVC는 서버 측 애플리케이션을 대상으로 하기 때문에, HTTP요청과 응답을 처리하는데 중점을 둔다.
반면, Cocoa나 Android에서의 MVC는 클라이언트 측 애플리케이션을 대상으로 하기 때문에 사용자 인터페이스와 사용자 입력을 처리하는데 중점을 둔다.

MVC에서 가장 중요한 것은 Model,View,Controller의 역할과 책임을 이해하고, 이 구성 요소들을 적절히 분리하여 애플리케이션을 설계하는 것이다.
이 원칙을 따르면, 애플리케이션의 구조가 명확해지고 코드의 관리가 용이하며, 애플리케이션의 유연성과 확장성이 향상될 것이다.
결국 패턴이라는 것도 많은 경험을 통해 만들어진 이론이니까 무조건 나의 상황에 맞다고 생각하는 것은 위험할 수 있다!

자료를 찾아보면서 MVC와 Layered Architecture를 같게 생각하는 글들도 있어 찾아보게 되었다.
실제로 두 패턴 모두 애플리케이션의 관심사를 분리하여 코드의 재사용성을 높이고 유지보수를 용이하게 하는 것을 목표로 했다.
하지만, MVC는 사용자 인터페이스를 가진 애플리케이션을 대상으로 하고, Layered Architecture는 애플리케이션의 전체 구조를 대상으로 했다.
해당 그림이 잘 설명하고 있는데, 그림에서 주의할 것은 MVC의 model과 ModelAndView는 다른 역할을 한다.
ModelAndView는 Controller가 특정 View로 데이터를 전달하는 역할.
MVC의 model은 비즈니스 로직과 데이터를 처리하는, 그림에서는 Service Layer 이후라고 생각할 수 있다.