MVC 패턴

요약

Model - View - Controller 의 약자. 모델은 데이터, 뷰는 뷰, 컨트롤러는 둘의 연결. 모델과 뷰는 완전독립,

C → M, V 는 가능. M → C 또는 V → C 는 바람직하지 않음. 노티, 딜리게이트 등을 이용함.

장점: 각각의 역할을 독립시켜 생산성이 높다.

단점: 모델의 네트워크 처리, 뷰의 라이프 사이클 등이 컨트롤러에 집중되서 controller 의 크기가 커질 수 있음.

---

MVC 패턴이란 애플에서 iOS를 개발할 때 권장하는 아키텍처 모델이다.
아키텍처 모델은 프로그램의 유지보수를 쉽게, 단위 테스트를 할 수 있게 하는 것을 목표로 둔다.
최근에는 MVC 의 문제점을 극복하기 위해 MVC-N, MVVM, MVP 등 여러 모델들이 나오고 있지만, 먼저 기본이 되는 MVC 를 제대로 알고 활용할 줄 알아야 문제도 보이고 다른 디자인의 필요성도 보이는 법이겠다.

오늘은 기본적이지만 중요한 MVC 패턴을 알아보자.

 

MVC 는 Model - View - Controller 의 약자이다.
각각 역할을 분담해 각자의 할 일만 잘~ 하는것이 목표다. 각각의 역할을 알아보자.

Model

Model 은 Data의 로직을 담당한다. 데이터를 계산하고 저장한다. 필요하다면 외부에서 데이터를 받아오는 역할도 한다.
계산기를 예로 들면, '계산을 하고 결과를 저장' 까지만 하는 것이다.

View

View 는 말 그대로 화면에 보여지는 부분을 담당한다. 계산기 결과를 화면에 보여주는 UI를 담당한다.

Controller

Controller 는 쉽게말해 Model과 View 를 연결해주는 역할을 한다.
Model 에서 계산을 했다면 그 결과를 View 에서 보여줘야 하는데 이 결과를 전달하는 역할을 하는 것이다.

 

여기까지 이해했다면, 자연스럽게 다음 그림이 이해가 될 것이다.

 

Stanford iOS 강의 cs193p 의 강의 중의 슬라이드 화면이다.

 

앞서 Controller 는 Model 과 View 를 연결시켜주는 역할을 한다고 했다. 굳이 중간 다리를 하나 더 둔다는 것은 Model 과 View 는 완전하게 독립(independent) 시키겠다는 것을 의미한다. Model 과 View 사이에 노란색 선으로 벽이 있는 것이 보일 것이다.

 

그럼 Model 과 Controller , View 와 Controller 를 살펴보자. Controller 는 모델과 뷰를 모두 연결할 수 있으니 Controller → Model, Controller → View 는 자연스럽게 접근이 가능하다.

 

Model → Controller, View → Controller 는 어떨까? 결론부터 말하자면 가능은 하지만,
하지 않는 것이 좋다. 이는 MVC 패턴에 어긋난다.
그렇다면 값의 변화, 사용자의 입력과 같은 View 의 변화는 어떻게 감지할까?

 

MVC 에서 Model 과 View 에서 Controller 에게
직접적인 전달은 권장하지 않고 다른 방식을 사용하도록 권한다.

 

Model → Controller

iOS 에서는 Model → Controller 는 Notification(또는 KVO) 를 사용해 해결한다. Model 에서 바뀐 값을 직접 전달하는게 아니라 바꼈다고 알리면 Controller 에서 이를 감지하여 처리하는 것이다. 얼핏보면 그게 그거라고 생각할 수 있지만, Model 에서는 Controller 를 알 필요가 전혀 없다.

 

View → Controller

View 의 변화는 Delegate 또는 DataSource 를 사용한다. Delegate 는 위임한다는 뜻으로, View 의 변화 즉, 사용자의 입력, 터치, 드래그 등의 event 가 발생했을 때 delegate 에게 위임한다. 따라서 delegate 에서 처리할 이러한 처리 로직은 Controller 에 위치한다. 마찬가지로 View 에서는 Controller 를 알 필요가 없다.

 

MVC 의 장점과 단점

MVC 는 각각의 역할을 독립시켜 생산성을 높인다. 하지만 iOS 에서는 각 역할의 분리가 완전하지 않다. 실제로 Model 에서 처리해야 할 네트워크 통신에 관한 코드도 Controller, View 의 생명 주기에 관한 코드도 Controller 에 위치하게 되어서 Controller 의 크기가 지나치게 커지는 경향이 있다.

 

이러한 문제점을 극복하고자 맨 처음에 말했던 다른 디자인 패턴들이 등장하고 있는 것 같다. 하지만 이러한 디자인 패턴은 MVC 를 열심히 사용하고 문제에 부딪혀 봤던 선배 개발자들의 고민의 흔적이다. 그 결과를 감사히 알고 사용하는 것은 좋지만, 문제를 겪어 보지도 않고 MVC 는 문제가 있어서 다른 걸 사용하는게 좋다더라, 단순히 코드가 지저분해서 다른 아키텍처를 사용해봐야지, 라고 생각해서 사용하는 것은 바람직하지 않다고 생각한다. 항상 정답은 없고 상황에 따른 최선이 있기 마련이다. 특히나 디자인 패턴은 각각을 올바르게 이해하고 열린 사고로 끊임없이 고민해야 할 문제라고 생각한다.

 

 

참고

MVC 패턴 in iOS