토요일, 12월 8

MVC? MVP? 무엇에 쓰는 패턴인고?

MVC = Model View Controller
MVP = Model View Presenter
MVP & MVC


0. MVC, MVP 패턴의 등장 이유
1. MVC 패턴은 무엇인가? 
2. MVP 패턴은 무엇인가? 
3. 결론


0. MVC, MVP 패턴의 등장 이유

GUI 의 등장. 보다 효율적으로 사용자와 상호작용 할 수 있는 구현의 필요성.  



1. MVC 패턴은 무엇인가? 

MVC 패턴은 MVC = Model View Controller, 3가지 요소로 나누고자 하는 의도에서 나왔다.
과거 OS에서 GUI를 구성할 때 View가 Event를 handle하지 못했고 때문에 Controller가 사용자와의 상호작용을 전담하게 되면서 나온 구도라고 한다.

MVC 패턴이 뭐길래? 
MVC 패턴은 Model View Controller를 분리하고자 나온 개념이다. 그 이유는 각 요소를 분리하여 보다 '잘' 만들고자 하는데 있다. 객체지향은, 기본적으로 객체간의 상호 의존성을 줄여 재사용성과 유지보수를 최적화 하는데 목적이 있다.

 하지만 MVC 패턴은 View와 Model 을 분리할 수 없는 의존성의 한계가 있다. 
 
MVC Model 1

MVC Model 1 은 극단적으로 Model과 View가 상호 의존이 심해, 거의 구분이 불가능한 상태를 가지고 있다. 이를 말로 표현하자면 사용자가 요청에 따라 Controller가 하나의 DAO를 가져오며 ( Bean 같은거 ) 이 DAO 를 보여주기 위해 View를 만든다. 라고 할 수 있다.

즉, DAO가 바뀌면 View는 당연히 새로 만들어야 하는 구조였다. 

이와 같은 문제에 MVC Model 2이 등장하게 되었는데, 
골자는 View를 갱신시켜주는 Observer를 통해 의존성을 감소시키는 것이었다.

MVC Model 2

얘기를 진행하기 전에 MVC Model 2에서 Controller 에 Servlet이 온 점을 먼저 집고 넘어가고자 한다. 기본적으로 Controller는 Controller의 역할을 할 수 있으면 된다. 그러므로 Controller가 JSP로 구현되었어도 같은 역할을 수행한다면 Servlet과의 차이는 없다. 

MVC Model 2 Diagram
MVC Model 2 에 새로 등장한 Observer interface는 Model과 View의 의존성을 어느 정도 경감시켜준다고 한다. ( 본인은 잘 모르겠지만... ) MVC Model 2에는 Flow SynchronizationObserver Synchronization 패턴이 적용됐다고 한다.

Web을 예로 든다면, 
Model 1  : controller 가 요청을 받음 -> Model 갱신 -> Model 에 따라 View 만듬
Model 2  : controller 가 요청을 받음 -> Model 갱신 -> Observer에게 갱신 요청함 -> View에서 갱신이 됨. 

Android를 예로 든다면, 
Model 1  : onItemClickEvent 받음 -> Model 갱신 -> 새 ListView 만듬. 
Model 2  : onItemClickEvent 받음 -> Model 갱신 -> Adapter에게 Notify함 -> View 갱신


MVC 의 패턴 한계 
MVC 패턴에 대한 한계점은 엄청 많은거 같은데, 몇 가지만 얘기해보고자 한다. 
첫 째는, MVC 패턴 자체로서가 아닌 타 패턴( 특히 Observer의 등장 )과 함께 사용해야 본 의도인 MVC의 삼권 분리를 이룰 수 있다는 점으로 사실상 패턴으로서의 한계점을 드러내는 점이라고 할 수 있다. 

둘 째는, Observer의 등장으로 인해 신경써야 할 일이 더 많아졌다는 것이다. Model1에서는 하나의 Model에 하나의 View을 만들었기에 현재 어떤 View가 보여지고 있는지 신경쓸 이유가 없었다. Controller가 명령하면 보여질 Model에 보여질 View를 사용하면 됐으니까. 하지만 Observer를 사용하게 되면서 현재 보여지는 View 뿐 아니라 동시에 View의 교체 혹은 갱신 시에 Flow의 Synchronize 까지 신경써야 된다.

셋 째는, Android를 개발하는 입장에서 가끔 답답함을 느끼게 되는 Model의 갱신 문제인데, 어떤 블로그에서는 이를 이렇게 표현합니다.  - "예를 들어 사용자가 체크 버튼을 눌렀을 때, 해당 갱신 기록을 어디서 처리해야 할까요?" 

여러 분의 생각은 어떠한지 궁금하다. 
현재 Android 에서 adapterView를 상속하는 View들은 모두 Observer 패턴이 적용되며, 이는 Adapter로 표현된다. MVC Model 2 에서는 앞의 질문에 대한 답을 이렇게 한다.

[ 사용자의 요청 -> Controller -> Model 갱신 -> Observer에게 갱신 명령 -> Observer에 의한 View 갱신(체크) ] 이 된다. 딱 봐도 뭔가 느낌이 미려하지가 않다. 

-기타
그 외에 Observer 패턴 자체 문제로 디버깅이 어렵다 등이 있다고 합니다. 


2. MVP 패턴은 무엇인가? 


MVP 는 Model View Presenter 로 구성한 GUI 용 패턴이다.

앞서 MVC 패턴 등장할 당시의 OS 환경에서 GUI를 구성할 때 View가 Event를 handle하지 못했고 때문에 Controller가 사용자와의 상호작용을 전담하게 되면서 나온 구도라고 했다.

현재의 OS는 View에서 Event의 Handle 을 할 수 있으므로, View 가 Event를 Handling 한다. 그리고 View 는 Presenter와 약속된 interface로서 Event 를 전송하고 Presenter는 해당 Event를 통해 Model을 갱신하는 구조이다.

MVP 패턴 예 
 앞서 예를 든, Check box 의 선택을 비교해서 생각해보자.
 MVC : onItemClickEvent 받음 -> Model 갱신 -> Adapter에게 Notify함 -> View 갱신
 MVP : onItemClickEvent 받음 -> View 갱신 -> Presenter에게 apply 함 -> Model 갱신


 View와 Presenter는 interface로서 통신한다. 
MVP 패턴은 Model과 View의 의존성을 경감시킴으로 진정한 View와 Model의 재사용성을 보장할 수 있다.

"예를 들어 사용자가 체크 버튼을 눌렀을 때, 해당 갱신 기록을 어디서 처리해야 할까요?"

라는 의문에 대해서 MVP 패턴은 이렇게 대답할 수 있다. 
[ 사용자의 요청 -> 사용자와 상호작용하는 View에서 Handle -> View 갱신(체크) -> Presenter 에 apply -> Presenter 에서 Model 갱신 ]

너무나 직관직이다. 
이것은 개발하는 사람에게도, 코드를 보는 사람에게도 직관적으로 느껴질 것이다. 

다음에 기회가 된다면 두 코드가 얼마나 다르게 느껴지는지 비교해보도록 하겠습니다.


3. 결론


MVP 가 좋음. MVP 를 씁시다. ^0^/


References

http://www.martinfowler.com/eaaDev/PresentationModel.html
http://www.martinfowler.com/eaaDev/uiArchs.html
http://aspiringcraftsman.com/2007/08/25/interactive-application-architecture/
http://blog.daum.net/picus2/186
http://msdn.microsoft.com/en-us/magazine/cc188690.aspx








댓글 없음:

댓글 쓰기