MVC 패턴이란?
모델-뷰-컨트롤러(model–view–controller, MVC)는 소프트웨어 공학에서 사용되는 소프트웨어 디자인 패턴이다. 이 패턴을 성공적으로 사용하면, 사용자 인터페이스로부터 비즈니스 로직을 분리하여 애플리케이션의 시각적 요소나 그 이면에서 실행되는 비즈니스 로직을 서로 영향 없이 쉽게 고칠 수 있는 애플리케이션을 만들 수 있다. MVC에서 모델은 애플리케이션의 정보(데이터)를 나타내며, 뷰는 텍스트, 체크박스 항목 등과 같은 사용자 인터페이스 요소를 나타내고, 컨트롤러는 데이터와 비즈니스 로직 사이의 상호동작을 관리한다.
출처: MVC - wikipedia
- 사용자가 웹사이트에 접속 (Users)
- Controller는 사용자가 요청한 웹페이지를 서비스하기 위해서 모델을 호출 (Manipulates)
- Model은 데이터베이스나 파일과 같은 데이터 소스를 제어한 후 그 결과를 Return
- Controller는 Model이 리턴한 결과를 View에 반영 (Updates)
- 데이터가 반영된 View는 사용자에게 보여짐 (Sees)
핵심은 MVC 패턴을 사용하면 사용자 인터페이스로부터 비즈니스 로직을 분리하여 비즈니스 로직을 쉽게 고칠 수 있는 애플리케이션이 된다는 것이라 생각됩니다.
그리고 과거에는 View에 모든 비즈니스 로직까지 넣어 코드의 길이가 길어지고 유지보수가 힘들었으나 최근에는 MVC모델은 코드를 3가지 형태로 나누어 개발을 하는 MVC가 기본적인 디자인패턴이 되어 사용되고 있다고 합니다.
=> 유지보수가 편해지는 코드 구성 방식
Model, View, Controller
Model
Model은 Data와 애플리케이션이 무엇을 할 것인지를 정의하는 부분으로 내부 비즈니스 로직을 처리하기 위한 역할을 합니다.
- 즉, 모델은 컨트롤러가 호출을 하면 DB와 연동하여 사용자의 입출력 데이터를 다루는 일과 같은 데이터와 연관된 비즈니스 로직을 처리하는 역할을 합니다.
- 데이터 추출, 저장, 삭제, 업데이트 등의 역할을 수행합니다.
Model은 다음과 같은 규칙을 갖고 있습니다.
-
사용자가 편집하기를 원하는 모든 데이터를 가지고 있어야 합니다.
-
View나 Controller에 대해서 어떤 정보도 알지 말아야 한다.(View와 Controller에 의존하지 않아야 한다)
-
변경이 일어나면, 변경 통지에 대한 처리방법을 구현해야만 한다.
View
- View는 사용자에게 보여주는 화면(UI)이 해당됩니다.
- 사용자와 상호작용을 하며 컨트롤러로부터 받은 모델의 결과값을 사용자에게 화면으로 출력하는 일을 합니다.
- MVC에서는 여러개의 View가 존재할 수 있습니다.
- Model에서 받은 데이터는 별도로 저장하지 않습니다.
View는 다음과 같은 규칙을 갖고 있습니다.
- Model이 가지고 있는 정보를 따로 저장해서는 안됩니다.
- Model이나 Controller와 같이 다른 구성요소들을 몰라야 합니다.
- 변경이 일어나면 변경 통지에 대한 처리방법을 구현해야만 합니다.
📌 Model과 View는 서로의 존재를 몰라야 합니다.
Controller
- Controller는 Model과 View 사이를 이어주는 인터페이스 역할을 합니다.
- 즉, Model이 데이터를 어떻게 처리할지 알려주는 역할을 합니다.
- 사용자로부터 View에 요청이 있으면 Controller는 해당 업무를 수행하는 Model을 호출하고 Model이 업무를 모두 수행하면 다시 결과를 View에 전달하는 역할을 합니다.
Controller는 다음과 같은 규칙을 갖고 있습니다.
- Model이나 View에 대해서 알고 있어야 합니다.
- Model이나 View의 변경을 모니터링 해야 합니다.
- 에) 쇼핑몰에서 상품을 검색하면 그 키워드를 컨트롤러가 받아 모델과 뷰에 적절하게 입력을 처리해야 한다.
Model: 데이터와 관련된 부분
View: 사용자한테 보여지는 부분
Controller: Model과 View를 이어주는 부분
MVC1 패턴
MVC1은 WAS(Web Application Server)에서 모든 파일에 클라이언트가 요청한 로직을 처리하는 경우다.
JSP(Java Server Page)에서 View, Controller의 역할을 담당하며 그 결과를 클라이언트에게 반환한다.
MVC1은 아키텍처가 간단하고 JSP에 거의 모든 로직을 집어넣기 때문에 작은 웹 어플리케이션을 제작할 때는 큰 무리가 없지만 대규모 웹 어플리케이션을 제작하게 될 시 유지보수에 큰 어려움이 따른다.
MVC2 패턴
MVC2는 이 MVC1방식을 보완한 아키텍처다.
MVC 패턴에 맞게 Model, Controller, View 부분로 모듈화 됐고 JSP는 로직 처리가 없이 단순히 Client에게 보여지는 뷰만을 담당한다.
이 방식은 각각이 모듈화되어 있어 유지보수가 매우 쉬워지는 큰 장점이 있다.
현재의 웹 어플리케이션은 거의 MVC2방식을 따른다 보면 된다.
MVC를 지키면서 코딩하는 법
-
Model은 Controller와 View에 의존하지 않아야 한다.
(Model 내부에 Controller와 View에 관련된 코드가 있으면 안 된 다.)
-
View는 Model에만 의존해야 하고, Controller에는 의존하면 안 된다.
(View 내부에 Model의 코드가 있을 수 있고, Controller의 코드가 있으면 안 된다.)
-
View가 Model로부터 데이터를 받을 때는, 사용자마다 다르게 보여주어야 하는 데이터에 대해서만 받아야 한다.
-
Controller는 Model과 View에 의존해도 된다.
(Controller 내부에는 Model과 View의 코드가 있을 수 있다.)
- View가 Model로부터 데이터를 받을 때, 반드시 Conroller에서 받아야 한다.
MVC의 장점
- 기능별로 코드를 분리하여 하나의 파일에 코드가 모이는 것을 방지하여 가독성과 코드의 재사용이 증가한다.
- 각 구성요소들을 독립시켜 협업을 할 때 맡은 부분의 개발에만 집중할 수 있어 개발의 효율성을 높여준다. <- 분업을 가능하게 해준다!!!
- 개발 후에도 유지보수성과 확장성이 보장된다.
MVC의 한계
Model과 View는 서로의 정보를 갖고 있지 않는 독립적인 상태라고 하지만 Model과 View사이에는 Controller를 통해 소통을 이루기에 의존성이 완전히 분리될 수 없습니다.
-> View와 Model사이의 의존성이 높습니다. 이는 앱이 커질수록 유지보수가 어려워집니다.
그래서 복잡한 대규모 프로그램의 경우 다수의 View와 Model이 Controller를 통해 연결되기 때문에 컨트롤러가 불필요하게 커지는 현상이 발생하기도 합니다.(그래서 Service단이 존재합니다. Service단은 컨트롤러의 비중을 줄여주기 위해서 실무에서 많이 사용합니다.)
이러한 현상을 Massive-View-Controller현상이라고 하며 이를 보완하기 위해 MVP, MVVM, Flux, Redux등의 다양한 패턴들이 생겨났습니다.
MVC의 대안
- MVC: 컨트롤러와 뷰의 강한 결합
- MVP: Presenter를 사용하여 뷰의 인터페이스 결합
- MVVM: View가 ViewModel을 구독
MVP
MVP 패턴은 MVC와 유사한 디자인 패턴입니다. 이는 MVC 패턴에서 파생되었기 때문인데요, 기존 Controller의 역할을 Presenter가 한다고 보시면 됩니다.
Presenter
-
Presenter는 View를 통한 사용자의 입력을 받습니다.
-
그 다음 Model에 도움을 받아 사용자의 데이터를 처리하고 결과를 View로 다시 전달합니다.
-
Presenter는 interface를 통하여 View와 상호작용합니다.
-
interface는 필요한 데이터를 전달하는 presenter 클래스에서 정의됩니다.
-
액티비티나 프래그먼트와 같은 view 구성요소는 이 인터페이스를 구현하고 원하는 방식으로 데이터를 랜더링합니다.
-
MVP 패턴에서 Presenter는 Model을 조작할 뿐만 아니라 View를 업데이트합니다.
-
Presenter와 View는 서로 완전히 분리되어 인터페이스를 통해 통신합니다. 이 방식은 MVC보다 단위테스트가 훨씬 쉬워집니다.
장점
앞서 말했듯이 MVP패턴은 인터페이스를 통해 통신하기 때문에 MVC의 단점으로 지적되었던 View와 Model사이의 의존성이 없습니다.
단점
View와 Presenter사이의 의존성이 높고, 앱이 커질수록 이 의존성은 더 강해집니다.
Model - View - Model (MVVM)
MVVM 패턴은 양방향 데이터 바인딩을 지원합니다. 이에 따라 뷰 모델 안에 있는 데이터의 변화를 View에 전파합니다. 일반적으로 옵저버 패턴을 활용하여 View Model의 변경사항을 Model에게 알립니다.
Model & View
MVC, MVP와 같은 컨셉으로 사용됩니다.
ViewModel
- ViewModel
- View 상태를 유지 및 변화시킴
- View에 대한 작업의 결과로 Model을 조작
- View에서 발생되는 이벤트를 트리거하는데 도움이 되는 메서드, 명령, 또는 다른 속성들을 노출하는 역할
View
- ViewModel에 관한 참조를 가지고 있지만, ViewModel은 View에 관한 정보를 모릅니다.
- View와 ViewModel사이의 n:1의 의존관계가 생기며 다수의 View는 하나의 ViewModel에 매핑될 수 있습니다.
- 이로서 ViewModel은 다수의 View에 대해 완전히 독립적입니다.
특징
언뜻 보기에는 MVP와 비슷한 부분이 많습니다.
-
그러나 MVP는 View와 Presenter 사이의 의존관계가 1:1로 형성
-
MVVM은 View와 ViewModel사이의 관계가 1대n으로 되어있습니다.
또한 데이터 바인딩을 이용한다면 View와 ViewModel 사이의 의존성을 없앨 수 있습니다.
장점
테스트 및 확장 용이성이 증가하고, 데이터 바인딩을 사용한다면 View와 ViewModel사이의 의존성 또한 없어집니다.
단점
ViewModel의 설계가 쉽지 않습니다.
참고
