디자인 패턴 : MVC 패턴, MVP 패턴, MVVM 패턴
MVC 패턴은 모델(Model), 뷰(View), 컨트롤러(Controller)로 이루어진 디자인 패턴이다.
애플리케이션 구성 요소를 세 가지 역할로 구분하여 개발 프로세스에서 각각의 구성 요소에만
집중해서 개발 할 수 있다.
재사용성과 확장성이 용이하다는 장점이 있지만
애플리케이션이 복잡해질수록 모델과 뷰의 관계가 복잡해지는 단점이 있다.
- 모델(Model)
모델은 애플리케이션의 데이터인 데이터베이스, 상수, 변수를 뜻한다.
- 사용자가 편집하길 원하는 모든 데이터를 가지고 있어야 한다.
- 뷰나 컨트롤러에 대해서 어떠한 정보도 알지 말아야 한다.
- 변경이 일어나면, 변경 통지에 대한 처리방법을 구현해야 한다. - 뷰(View)
뷰는 inputbox, checkbox, textarea 등 사용자 인터페이스 요소를 보여주는 부분이다.
모델이 가지고 있는 정보를 따로 저장하지 않아야 하며 단순히 화면만 표시해주는 부분이다.
- 모델이 가지고 있는 정보를 따로 저장해서는 안된다.
- 모델이나 컨트롤러와 같이 다른 구성 요소를 몰라야 한다.
- 변경이 일어나면, 변경 통지에 대한 처리방법을 구현해야 한다. - 컨트롤러(Controller)
컨트롤러는 하나 이상의 모델과 하나 이상의 뷰를 잇는 다리 역할을 하며
이벤트 등 메인 로직을 담당한다. 또한, 모델과 뷰의 생명주기도 관리하며,
모델이나 뷰의 변경 통지를 받으면 이를 해석해서 각각의 구성요서에 해당 내용을 알려준다.
- 모델이나 뷰에 대해서 알고 있어야 한다.
- 모델이나 뷰의 변경을 모니터링 해야한다.
MVC 패턴을 사용하면 비즈니스 로직과 UI로직을 분리하여 유지보수를 독립적으로 수행가능하고
애플리케이션의 확장, 유연성에 유리하고 중복 코딩의 문제점을 제거해줄 수 있으나
컨트롤러에 의해서 뷰에 연결될 수 있는 모델도 여러 개가 될 수 있어 뷰와 모델이 의존성을 띄게 된다.
MVP 패턴
MVP 패턴은 MVC 패턴으로부터 파생되었으며 MVC에서 C에 해당하는 컨트롤러가 프레젠터(presenter)로 교체되었다.
- Presenter
프레젠터는 View를 통해 사용자로 부터 입력받은 후, Model의 도움을 받아 데이터를 처리하고
결과를 다시 View로 전달한다.
프레젠터는 Model를 조작하고 View도 업데이트 한다.
MVC 패턴에서는 컨트롤러에 의해 Model 과 View가 의존성을 띄게 되었는데
프레젠터를 만듬으로써 이 부분을 보완했다.
즉, View 와 Presenter는 서로 완전히 분리되어, 인터페이스를 통해 통신한다.
(근데 View 랑 Presenter는 서로 의존함.. 음.. 그럼 구지?)
또한 MVP 패턴을 사용하면 단위 테스트가 훨씬 쉬워진다.
MVVM (Model - View - ViewModel)
MVVM 패턴에서는 뷰와 뷰 모델 사이의 양방향 데이터 바인딩을 발견할 수 있다.
뷰 모델 안에서 그리고 뷰에게 수정사항들을 자동적으로 이동시킨다.
- View Model
뷰 모델의 책임 중 하나는 메서드와 함수들을 나타내는 것이다.
모델을 작동하기 위한 명령을 나타내고, 뷰의 상태를 유지시키고, 뷰의 이벤트를 활성화시킨다.
MVVM 패턴의 장점
MVVM 패턴을 사용하면 적절한 방법으로 구현되었다는 전제 하에, 모든 내부적, 외부적 의존성을
코어 로직을 포함한 코드로부터 유지하기에 테스트가 용이하다.
또한 확장성과 동시에 유지보수성도 얻게 되고, 뷰를 추상화해서 만든 패턴이기에
비지니스 로직 뒤에 있는 코드가 줄어들고 로직과 프레젠테이션 계층이 느슨하게 결합된다.
추가적으로 어설픈 UI 자동화 도구 없이 테스트가 가능하다.