나무's 블로그

이전까지 내가 사용하던 디자인 패턴은 MVC 의 패턴으로 알고 있었다.

하지만 이번에 MVVM을 공부하면서 좀 더 자세한 MVC MVP MVVM의 특징들을 알고 나서는

'나는 단지 스파게티를 만드는 요리사였구나' 싶었다.

자세한 내용들은 다른 블로그나 자료들이 많으니 간략히 혼자 정리하는 시간을 가질 것이다.

처음으로 Design Pattern을 공부하는 가장 큰 이유는 유지보수 때문이다.

다른 사람이 봤을 때 가독성 또한 좋아질 것이며, 스파게티 요리사가 만든 코드를 봤을 때는 그 요리사만이 알 수 있기 떄문에 이러한 Pattern을 공부한다. 

또한 이것이 정해진 정답은 아니고, 섞어서 프로젝트마다의 장,단점을 파악하여 쓰는 것이 가장 적절하다고 생각한다.

MVC - Model View Controller 로 이루어졌으며

• Model - 사용자가 만든 Class 등이며 DB, Web의 Resource 등
• View - UI를 담당한다. 컨트롤러와 통신(이벤트 ..)
• Controller - 가장 바쁘다. 상호작용을 담당하고 주로 Activity or Fragment로 표현된다.

MVP - Model View Presenter 로 이루어졌으며

• Model - MVC의 Model과 차이가 없다
• VIew - MVC의 Activity / Fragment가 이제는 View로 간주된다. View와 Presenter는 1:1로 대응된다
• Presenter - View와 Model을 이어준다. 내가 생각하는 Controller와의 차이점을 가장 쉽게 설명하는 것은 '이벤트가 발생했을 때 코드가 실행되는 순서' 이다. 

ex) 버튼을 눌렀을 때 이벤트가 발생하여 View의 TextView를 변경하는 코드라고 가정하자(MVC)

1. 버튼이 눌리면 Controller가 확인
2. Controller가 Model에서 Data 가져옴
3. 가져온 Data를 가공
4. 가공된 Data를 View의 Text에 써준다

ex) 버튼을 눌렀을 때 이벤트가 발생하여 View의 TextView를 변경하는 코드라고 가정하자(MVP)

1. 버튼이 눌리면 View가 확인
2. View가 Controller에게 Data 요청
3. Controller가 Model에게 Data 요청
4. 가져온 Data 가공
5. 가공된 Data를 View에게 뿌려줌
6. View가 Data를 Text에 쓴다

MVVM - Model View ViewModel 로 이루어졌으며 DataBiding을 사용하여 VIew와 Model의 연결을 위해 코드가 짧다. 사용하므로써 View와 ViewModel의 독립성이 높아진다.

• Model - MVC와 동일
• View - 화면의 layout, Activity/Fragment(UI를 담당)
• ViewModel - View에 연결할 Data를 Model에서 가져와 가공 및 Data 변경을 View에게 알림

요즘 가장 뜨고있는? Design Pattern으로 개발자가 아닌 사람이 봤을 때도 가독성이 좋다. 

쉽게 설명하자면 View는 UI만을 담당하고 LiveData or RxJava를 사용하여 ViewModel의 변수(Data)의 변경을 알게된다.

그 변경을 알게됐을 때 DataBinding을 통하여 자동으로 갱신하게 할 수 있으며, 그로 인해 코드가 줄어들게 된다.