🌱 What is MVC Design Pattern? (Stanford iOS Lecture)

 

 

MVC(Model-View-Controller)

: 세 개의 다른 group으로 앱 또는 소스코드를 나누는 방법이다.

 

• Model : Application이 무엇을 하는지 말한다. 화면에 어떻게 그려질 것인지에 대한 것과는 관련 없다. 즉, 어떻게 보여주는지가 아니라 무엇인지를 말한다는 것이다. 계산기 앱에서 Model == 계산하는 부분
• Controller : Model이 화면에 어떻게 표현될 것인지를 말한다. 기본적으로 모든 Controller에 들어가는 UI 로직 
• View : Controller의 Minion(하위그룹)이라고 보면 된다. Controller가 화면에 무언가를 보여주기 위해서 사용된다. Model에 들어있는 Button, Label, Table 등을 Controller가 보여주기 위해 필요한 것들이다. 사용자에게 입력을 받아 Model을 업데이트하기도 한다.

각 Group이 무엇을 하는지 아는 것도 중요하지만 가장 중요한 것은 이 group들간의 소통이다. 어떤 것이 가능하고 불가능한지, 소통이 허용될 때 iOS에서 어떻게 해야할지!

 

 

 

1. Controller → Model

 

언제든지 가능. Model의 모든 것을 알고 있고 보내고 싶은 메세지를 보낼 수 있다. Controller는 Model을 통제한다. Controller은 사용자에게 Model에 있는 것을 표현하거나 사용자로부터 정보를 받아 Model을 업데이트하기 때문에 전체적인 통제가 필요하다.

 

2. Controller → View

 

View는 Controller의 Minion이기 때문에 Controller에서 사용할 수 있다. 대부분의 controller - view 의 연결은 outlet에 의해 연결된다.  

 

3. Model ↔ View

 

두 group은 절대로 소통할 수 없다. Model은 UI와 독립적이다. 완전히 UI에 의존적인 View와는 이야기할 수 없다.

View와 Model간의 모든 소통은 Controller를 통해서 이루어진다. 

 

4. View → Controller

 

제한적이다. 될 수도 있고 안될 수도 있다. 사전에 미리 정해진 방식으로 소통한다. 만약 소통이 가능하게 하려면, 눈에 보이지 않도록 구조화되어야 한다. 눈에 보이지 않는 다는 뜻은 View에 있는 객체는 자신이 무슨 클래스에게 이야기하고 있는지 모른다는 뜻이다. Button(View)는 ViewController(Controller)에 대해 아는 것이 없다. 구조화된다는 것은, 객체에 대해 아는 바가 없기 때문에 제대로 미리 서술되어 있는 방식으로 소통해야 한다. 

 

 

= View의 minion이 controller에게 이야기하는 구조화된 방식 =

 

- target-action

controller가 자기 자신에 target 판을 걸어놓는데 @IBAction으로 메소드를 정의하면 된다. view가 controller에게 말을 걸고 싶으면 이 메소드를 호출하게 된다.

 

- delegate

예를 들어, 일반화된 view의 minion인 ScrollView가 Controller에게 "스크롤링 시작했어", "사용자가 이만큼 확대했어" 등을 알린다. Controller는 이것들에 대해서 알고 반응해야 한다. ScrollView같은 View는 무언가를 해도 괜찮은지 확신이 필요하다. "지금 수직으로 스크롤하는 것을 허용해야 할까?" 이런 것들을 Controller에게 묻고 싶을 것이다. 그러면 많은 메세지가 필요할 것이고, should/will/did 등이 포함된다. (View는 모든 Controller 혹은 관련된 Controller에게 질문을 하고 싶어하니까) Delegate라는 것을 통해서 이루어 진다. Minion은 Controller에게 어떠한 책임을 위임하고 있다. 

 

[작동 방식] delegate = view안에 있는 property. Controller가 will/should/did 같은 것을 실행하겠다고 약속하면 View는 Controller에게 이야기할 수 있을 것이다.

 

✲ protocol이란, 다른 것이 대신 실행하기로 약속된 메소드를 모아놓은 설명

 

 

View는 자신이 보여주고 있는 데이터를 소유할 수 없다. 그러면 어떻게 표시할 수 있을까? 

Controller에게 매번 물어보기 → Controller는 Model에서 데이터 가져오기 

will/did/should 대신 다른 프로토콜의 메세지를 받는다 

 

• 데이터를 달라고 하기
• 데이터가 몇 개 있는지 물어보기

 

View는 데이터에 대해 물어봐서 무슨 일이 생겼는지 알게 되고 이를 화면에 보여준다. 이것도 Delegation 과정으로 이루어지는데 이를 DataSource라고 부른다. 어떤 view에는 dataSource라는 property가 있고 이 protocol의 pointer는 다른 객체가 된다.  Controller는 자기자신을 그렇게 지정해서 View를 위해 데이터를 제공하는데 관여하게 된다. 

Controller는 View를 위해 Model의 데이터를 해석하고 구성하기, Model에게 View 입력 해석하기 등의 역할을 한다.

 

 

 

5. Model → Controller

 

Controller는 UI 로직을 다루고 Model은 UI와 별개이다. 따라서 Model 이 Controller에게 직접 이야기할 방법이 없다. 그런데, 만약 UI와 관계없는 Model이 값이 바뀌는 데이터를 가지고 있다면? 네트워크상에서 Model은 데이터를 대표하는데 누군가 network에 있는 무언가를 바꾼다면 Model은 Controller에게 이를 어떻게 알려줄까? 

 

Model은 Controller에게 직접 알려줄 수 없다. Model에 어떤 일이 일어나고 있는지 알고싶은 사람이면 그들에게 방송으로 말해준다. Model에 의해 이루어지는 모든 소통은 UI와 관련없다. 이건 Model 안에 있는 데이터에 관련한 것이다. [데이터가 있고 변경되었다]와 같은 메세지들이 Model에서 흘러나온다. 

Model에 채널을 고정(데이터변화를 보기 위해 )하고 있는 것은 Controller

Controller는 데이터를 화면에 보여주기 위해 일반화되어 있는 View를 설정한다. 

 

💡Model은 앱을 설계하는 쪽에 가깝다. (Controller,View는 UI에 가깝고) 모델을 설계하려면 앱이 근본적으로 무엇을 하는지 생각해야 한다. 알고리즘, DB 같은 것들이 Model 안에 있다.

 

 

---

 

일반적으로 iOS에서 MVC 한 개가 아이폰 화면 한 개를 제어한다. 즉, MVC는 앱의 작은 한 부분을 제어한다. 진짜 앱을 만들기 위해서는 여러 MVC를 만들어서 결합해야 한다. 기본적으로 MVC는 또 다른 MVC의 View 일부로서만 일할 수 있다. 

iOS가 제공하는 TabBarController 같은 몇몇 MVC는 View의 일부로서 3, 4개의 별개의 MVC를 가질 수 있다. 아래에 있는 각각의 탭을 누를 때마다 다른 MVC를 볼 수 있다.