Stanford IOS 강좌를 보며 정리해봄
What your application is(but not how it is displayed)application이 무엇을 하는지를 말한다. 화면에 어떻게 그려질 것인가에 대한 것과는 관계가 없다.- 계산기를 예를들면 실질적인 계산을 하는 부분
Your Controller's minions컨트롤러의 미니언(하위종속자)이다.- 모델에 들어있는 버튼, 레이블, 테이블등을 컨트롤러가 보여주기 위해 필요한것들
How your Model is presented to the User(UI logic)모델이 스크린에 어떻게 표현될것인지 기본적으로 모든 컨트롤러에 들어가는 UI logic이다,
- Controllers can always talk directly to their Model.
- Controllers can also talk directly to their View
모든 컨트롤러의 미니언(View)와 연결은 outlet으로 이루어진다.
(이전 강의)계산기를 만들때 썼던 display에서 display는 Instance variable였고, Optional UILabel이였다.
이 연결은 컨트롤러가 뷰에게 이야기하는 방식을 의미한다.
- The Controller sets itself as the View's delegate(뷰의 미니언은 컨트롤러에게 어떠한 책임을 위임하고 있다) ->
delegate - View ---[delegate]--> Controller(
Should,will,did) - delegate가 작동하는 방식은
delegate는 그냥 view의property인데 그 프로퍼티의 클래스가 뭔지 물어볼지도 모르는데 View는ViewController에 대해 아무것도 모르니까 class가 되지는 않는다. 이런걸 두고 swift에서는protocol이라고 부른다.
다른녀석이 대신 실행하기로 한 약속된 메소들을 모아놓은 설명
다시 말해 컨트롤러가 will, should, did같은 것을 실행하겠다고 약속하면 뷰는 컨트롤러에게 이야기할 수 있다. 그 클래스를 몰라도
Views do not own the data they display(뷰는 자신이 보여주고 있는 데이터를 소유 할수 없다.)
그래서 뷰는 항상 컨트롤러에게 물어보고 컨트롤러는 모델에서 데이터를 가져온다.
이건 다른종류의 프로토콜이다. will, did, should대신 다른 프로토콜의 메세지를 받는다.
뷰는 데이터를 달라고 하거나 데이터가 얼마나 있는지 같은 걸 물어본다. 뷰는 데이터에 대해서 물어보고 무슨일이 생기고 있는지 알게 되고 그걸 화면에 보여준다.
여기 쓰이는
delegate를data source라고 부른다(모델이 아니다).
(Controllers are alomost always that data source(Not Model!))
그래서 어떤 View에는 data source라는 프로퍼티가 있고 이 프로토콜의 포인터는 다른 객체가 된다.
Can the Model talk directly to the Controller?
Model이 직접 Controller에게 이야기 할 수 있을까?
절대 아니다 왜냐하면 컨트롤러는 UI로직을 다루고 모델은 UI와 별개이기 때문에 Model이 직접 Controller에 이야기 할 수 없다.
하지만 UI와 상관없는 모델이 값이 바뀌는 데이터를 가지고 있다면 어떻게 될까? 네트워크 상에서 모델은 데이터를 대표하는데 누군가가 네트워크에 있는 뭔가를 바꾸면 모델은 어떻게 컨트롤러에게 알려줄까?
이걸 하기 위해서 라디오 방송국 모델(그림 참고)을 이용해보자.
- 라디오 방송국은 모델이 자신의 방송국을 세우는 걸로 시작한다.
- 그리고 방송국은 흥미로운 일이 생길 때마다 방송을 한다.
- 그런 다음에 컨트롤러는 그 방송국에 채널을 맞추어 놓는다.
이렇게 하면 모델은 컨트롤러에게 직접 말하지 않아도 그 모델이 무슨 일이 일어나고 있는지 알고 싶어하는 사람이라면 그들에게 방송으로 말을 해준다.
Controllers(or other Model) "tune in" to interesting stuff
모덜에 의해 이뤄지는 라디오 방송국안의 모든 소통은 UI와 관련이 없다. 이건 모델 안에 있는 데이터에 대한것이다. 데이터가 있고 데이터가 변경되었다 같은 메세지들이 라디오 방송국에서 흘러나오는 것들이다.
라디오 방송국은 모델과 컨트롤러 사이가 아닌 다른 캠프(MVC)사이에도 적용할 수 있다.
그러면 모델에 직접 채널을 고정하고 있는 뷰를 새로 만들어서 컨트롤러를 거치는 걸 줄일 수 있을까?
답은 그렇게 할수 없다. 그런 방식으로 하지 않는다. 모델에 채널을 고정하고 있는건 컨트롤러이고 컨트롤러는 데이터를 화면에 보여주기 위해 일반화 되어 있는 뷰를 설정하는거다.
[Question]
컨트롤러하고 뷰는 뭔가 이해하기 쉬운데 UI를 보여주는 부분이니깐 반면에 모델은 뭔지 머릿속에 그려지가 쉽지않다.
[Answer]
모델은 앱을 설계하는 쪽에 가깝다.모델을 설계하려면 앱이 근본적으로 무엇을 하는지 생각해야 한다. 그게 어떻게 사용자에게 보여질지와는 관계가 없다. 예를들어 계산기 앱에서는 숫자가 보여지는 인터페이스가 있어서 3 x 5 = 이라고 입력하면 그 결과가 제대로 보여진다. 이게 UI 부분이다. 실질적으로 계산을 하는 곱셈등은 모델안에 있을것이다.모델은 어떻게 보여질지가 아니라 앱이 실제로 무엇을 하는지를 이해하려고 하는 부분에 대한것이다.그게 이 MVC 설계에세 구분해야만 하는 점이다. 어떻게 보면 알고리즘쪽에 가깝다. 데이터, 데이터베이스 같은 것들이 모델안에 있기 때문이다.
일반적으로 IOS에선 MVC 한 개가 아이폰 화면 한개를 제어한다. 혹은 아이패드 화면에서는 두 개나 세 개의 화면을 제어한다. 바꿔 말하면 MVC는 앱의 작은 한 부분을 제어하는 것이다.
진짜 앱을 만들기 위해서는 여러 MVC를 만들어서 결합해야 한다.
위와 같은 상황에서도 의사소통이 잘되어야 하는데 기본적으로 MVC는 또 다른 MVC의 뷰 일부로서만 일할 수 있다. 사진에 보이는 보라색으로 된 컨트롤러 어떤것을 봐도 다른 MVC로 향하는 모든 화살표가 뷰 쪽으로 가고 있다. 그러니깐 우린 늘 MVC를 다른 MVC의 뷰 일부로 생각해야 한다.
iOS가 제공하는 TabBarController같은 몇몇 MVC는 뷰의 일부로서 3, 4개의 별개의 MVC를 가질 수도 있다.
아래에 있는 각각의 탭을 누를때마다 다른 MVC를 볼 수 있다. 4개의 MVC로 앱을 만든것이다.
4개 중 하나는 촤상위 MVC인 TabBarController이고 나머진 각 탭에 해당하는 MVC일것이다. 이 MVC 3개는 서로가 완전히 독립되어 있을것이다. 이렇게 앱을 만들면서 각 MVC가 스스로 자립해 움직이길 원한다.
우리가 객체를 설계할 때와 같은 건데 객체 스스로가 완전히 자립하길 바라는 거다.
다른 객체 내부에서 일어나는 부분으로 접근하는 건 원치 않는다.