MVC(Model, View, Controller) 패턴

MVC 패턴

 처음 개발을 시작했을 때는 그저 화면이 원하는 방식으로 돌아가게 만들기에 급급해서 모든 것들은 ViewController에 구현했다.

 

 초반의 단순한 기능들을 구현하기에는 큰 무리가 없었지만, 통신을 시작히고 앱의 기능들이 복잡해지기 시작하니 문제가 발생하기 시작했다. 모든 것을 ViewController에서 핸들링 하기에는 코드가 복잡해지고 길어져 무리가 오기 시작했다.

 

 그래서 처음 적용한 디자인 패턴이 MVC 패턴이다. 이 패턴은 iOS 뿐만 아니라 소프트웨어를 만들 때 고려되는 디자인 패턴이기 때문에 안드로이드 앱이나, 웹에서도 동일하게 적용된다. 

인터넷에서 MVC 패턴을 검색하면 가장 많이 보이는 이미지 하지만 복잡하기 때문에 모르고 보면 이게 뭔가 싶다.

MVC는 세가지 컴포넌트의 약자이다.

Model, View, Controller

애플리케이션에서 각 객채들은 위 세 가지 컴포넌트 중 하나의 역할을 수행하게 된다. 즉, 세 개의 객체가 각각의 역할을 통해 하나의 애플리케이션을 구동하게 되는 것이다.

Model

UI와는 독립되어 애플리케이션에 관한 데이터를 담고 있다. UI와 관계가 없는 자체의 데이터를 가지고 조작하고 처리하는 논리 연산을 처리하게 된다. Model의 객체는 데이터를 직접적으로 사용자에게 제공할 수 없다. 즉, 어떤 변수를 Model이 관리하는지가 중요하다고 볼 수 있는데, UI를 관리하는 변수는 Model이 갖는 것이 아니고 VIewController에서 관리한다.

 

영화의 제목이 Spider-Man: No Way Home이라는 데이터는 애플리케이션이 갖는 데이터 이므로 Model에서 관리를 한다.

 

하지만 제목을 화면에 표시해주는 라벨에 보여 주 줄지 말지에 대해서는 앱의 데이터에 대한 모델이 아닌 뷰에 대한 데이터 이므로 Controller에서 소유하고 관리하는 것이다.

 

 

 

 

 

View

UI와 관련된 객체들로, UIButton, UIImageViewm UILabel 등을 포함하며 사용자가 보고 상호작용할 수 있는 객체들이다. 뷰의 집합이 곧 애플리케이션의 UI를 이루게 된다. 주의해야 하는 점은 뷰에서 모델이 가진 데이터를 보여줄 수는 있지만, 모델 객체와의 직접적인 링크는 없다는 점이다. 뷰는 모델과 직접적인 소통을 하거나 데이터를 받아올 수는 없으며 그저 Controller에게 데이터를 받아 보여주고, 사용자와 상호작용을 하게 된다.

Controller

애플리케이션을 관리하는 객체로, 어떻게 화면에 표시할 것인지에 대해 관심을 갖는다. 사용자가 보는 뷰와 모델 간의 중계자 역할을 하게 된다. 사용자가 버튼을 눌렀을 때 API를 호출하여 생성한 모델에 데이터를 저장하고, 이를 바탕으로 뷰를 그리게 된다. 

통신

그렇다면 각 객체는 어떻게 통신할까? 위 역할에서 설명했듯이 모델과 뷰 사이에는 직접적인 커뮤니케이션이 허용되지 않는다. 대신 뷰와 모델은 각각 컨트롤러와 통신함으로써 필요한 내용을 전달하게 된다.

1. 먼저 뷰가 사용자의 입력을 받아 이를 컨트롤러에 전달하게 된다. 

2. 뷰의 변화를 전달받은 컨트롤러가 해당 액션을 바탕으로 모델을 업데이트한다.

3. 모델은 자체 연산을 처리하고 뷰에 업데이트될만한 데이터를 컨트롤러에 전달한다.

 이때 모델은 직접적으로 컨트롤러에 전달할 수는 없고, Notification을 사용하게 되며, 이때 사용하는 Notification이 KVO이다.

4. 컨트롤러는 모델에게서 받은 데이터를 뷰에 업데이트해준다.

역할 묶기

하나의 객체에서 MVC컴포넌트를 합치는 경우도 있다. 예를 들면 View와 Controller를 묶어서 'ViewController'가 되는다. 같은 방법으로 Model과 Controller가 합쳐진 'ModelController'도 있다고 하지만 아직 본 적은 없다. 

 

참고 : Apple Developer Docsc

참고 : 블로그