MVC 패턴(Model-View-Controller)
Model
어플리케이션이 무엇을 할 것인지 정의
내부 비즈니스 로직을 처리(DB의 데이터를 조작하는 layer)
1) 사용자가 편집하길 원하는 모든 데이터를 가지고 있어야만 한다.
2) 뷰(View)나 컨트롤러(Controller)에 대해서 어떤 정보도 알지 말이야 한다.
3) 변경이 일어나면, 변경 통지에 대한 처리 방법을 구현해야만 한다.
View
사용자에게 보여지는 인터페이스
ex) 웹 - HTML
1) 모델이 가지고 있는 정보를 따로 저장해서는 안된다.
2) 모델이나 컨트롤러과 같이 다른 구성 요소를 몰라야 된다.
3) 변경이 일어나면, 변경 통지에 대한 처리 방법을 구현해야만 한다.
Controller
데이터(Model)와 인터페이스(View)의 상호 동작 관리
Model에 명령을 보내 데이터의 상태를 바꾸고, 어떤 화면(UI)을 사용자에게 보여줄지 View에 명령
MVC 패턴을 사용하는 목적
View와 Model 사이에 Controller를 두어 View와 Model의 의존성(Dependency)을 없앰
BUT
실제로는 View에서 Model을 이용하기 때문에 View와 Model은 의존적임
(Model update -> View update)
복잡한 대규모 프로그램을 개발하면서 문제점 확인됨
둘의 의존성을 완전히 분리하기 위한 새로운 패턴
1) 모델이나 뷰에 대해서 알고 있어야 한다.
2) 모델이나 뷰의 변경을 모니터링 해야 한다.
MVP 패턴(Model-View-Presenter)
MVC 패턴에서 Controller -> Presenter로 바뀜
Presenter : View의 인스턴스를 갖고 있고, View에서 요청이 발생하면 요청에 따라 Model의 상태를 변경시킴
-> View와 Model 사이에 다리 역할 수행
사용자 입력이 오면
MVC 패턴은 Controller부터 왔지만, MVP 패턴은 View에서 발생함
(대부분의 프레임워크는 URL 요청을 받으면 컨트롤러로 연결됨)
View에서 요청이 발생하면 Presenter로 전달 -> Presenter에서는 그 이벤트에 따른 Model의 상태를 UPDATE
이 패턴은 View와 Model의 의존성을 완전히 분리시켰지만, View와 Presenter의 관계는 일대일이어서 둘의 의존성은 깊다
둘의 의존성을 완전히 분리하기 위한 새로운 패턴
MVVM(Model-View-ViewModel) 패턴
Controller, Presenter -> ViewModel로 바뀐 모델
ViewModel : View를 나타내기 위한 Model
사용자 입력은 View에서 발생
입력이 오면 Command 패턴으로 ViewModel에 명령을 하고, ViewModel은 Model에게 필요한 데이터를 요청
Model은 응답하고 Data 바인딩을 통해 ViewModel의 값이 변화하면 바로 View의 정보가 바뀜
-> Command와 Data 바인딩을 통해 View의 의존성을 끊음
