레이블러리 앱을 개발하면서 MVVM 패턴을 적용시켜보았는데, 기존에 애플이 지원했던 MVC 패턴을 떠올리며 차이점이 무엇인지 정리해보고 싶어서 글을 쓰게 되었다.
MVC 패턴이란 ?
Model + View + Controller 구조의 디자인 패턴이다.
그렇다면 각각의 요소에 대해 알아보도록 하자 ~!
1. Model : 앱의 데이터와 관련된 내용을 담고 있다. 그리고 데이터를 관리하는 로직도 Model에 담기게 된다.
네트워크를 통해 받아오는 데이터나 영구적인 데이터를 다루거나 필요한 구조체를 만드는 경우 관련된 코드들은 Model에 담기게 된다. 대체로 Model은 UI와 직접적으로 연결되어 있지는 않다. 데이터 그 자체의 구조를 나타내는게 MVC 패턴에서 일반적이다.
- 데이터로 사용하는 구조체 ex) 레이블러리 앱으로 따지면, Label에 대한 속성을 정의했다. struct Label { id: String, name: String ... }
- 메모리에 영구 저장되는 데이터에 관련된 로직 ex) Realm DB에 저장할 Label 데이터와 관련된 로직
- 네트워크 로직 / 네트워크에서 받아온 데이터를 파싱하는 로직
- Extension 우리가 정의한 데이터 구조체의 확장(extension)또한 모델에 포함된다. ex) extension Label ~
2. View : 사용자에게 데이터를 보여주고, 데이터들을 어떻게 UI로 보여줄지 화면을 구성하는 내용을 담고 있다. View는 사용자와 Application의 Interface가 되므로, 사용자의 반응을 Controller로 전달해 주는 역할도 해야한다. View에서는 재사용성을 생각하며 코드를 짜면 효율적이다!! 보통 개발을 하게 되면, 비슷한 디자인이나 UI 컴포넌트들이 자주 등장하는데, 등장할 때마다 새로 만드는건 너무 비효율적이기 때문 !
레이블러리에서는 Search Bar가 여기저기서 등장한다. Search Bar를 따로 정의하여 재사용을 했다.
3. Controller : Model 과 View가 커뮤니케이션 하는 방법이다. MVC 패턴에 대한 그림을 봐도 짐작할 수 있듯이, Controller는 View와 Model 모두와 연결되어 있는 것을 볼 수 있다. View에서 유저의 입력이 일어나면, 입력에 대한 정보를 받고, 이 정보를 바탕으로 Model을 업데이트한다. 반대로 View에 띄워주기 위한 Data를 Model로 부터 가져오고, View 화면을 갱신하는 역할을 한다.
MVC 패턴의 장점
- 애플이 기본적으로 지원하고 있는 패턴이라 친숙하다. 스토리보드만 봐도 ViewController가 명시적으로 있다 !!
- 그래도 아키텍처 분리를 하는 작업이 상대적으로 적어서 개발 속도가 빠르므로, 규모가 작은 프로젝드에서 효율적이다.
MVC 패턴의 단점
- View와 Controller가 너무 밀접하게 연결되어 있어서 분리하기 힘들다.
- 즉, 이는 재사용성을 떨어뜨리게 되며, 대부분의 코드가 controller에 집중될 수 있다는 단점이 된다.
- 당연히 controller가 하는 역할이 많아지게되고, 복잡해지게 되면 유지보수하기 힘들것이다. ( 복잡한 컨트롤러를 뜯어 고치는 작업이라니.. 생각만해도 아찔하다)
최근 프로젝트를 진행하면서 MVVM패턴에 익숙해졌는데, MVC 패턴과 비교했을 때 MVVM이 유지보수하기 쉽다는 말이 정말 이해가 간다. 그렇지만 기존 Storyboard는 MVC를 지원했으며, MVVM에 비해서 구조도가 이해하기 쉽고, 컴포넌트를 분리할 것도 MVVM에 비해서는 상대적으로 적다.
