^앱 12개를 만들며 배우는 Swift4 & iOS11 아이폰 iOS 개발 강좌, Stanford iOS 한글자막 강의^

일반적으로 ios에서는 MVC한개가 아이폰 화면 한 개를 제어한다.

아이패드에서는 두, 세개의 화면을 제어할 수 있다.

즉 MVC는 앱의 작은 한 부분을 제어하는 것이다.

애플사의 제품들은 cocoa,cocoa touch 프레임워크를 사용하여 개발하는데

이 개발 방식이 아래 사진과 같다!

https://developer.apple.com/library/archive/documentation/General/Conceptual/CocoaEncyclopedia/Introduction/Introduction.html

이렇게 세 개의 다른 계층으로 앱 또는 소스코드를 나누는 방법을 MVC 디자인 패턴이라 한다.

모델계층

: application이 무엇을 하는지

컨트롤러계층

: 모델이 화면에 어떻게 표현될건지

역할 : 사용자에게 모델에 있는 것을 표현하거나 사용자로부터 정보를 받아 모델을 업데이트

뷰계층

: 컨트롤러의 하위종속자

컨트롤러 -> 모델

컨트롤러는 모델에게 언제든 이야기 할 수 있다.

모델의 모든것을 알고있고 보내고 싶은 메시지를 보낼 수 도 있다.

컨트롤러 -> 뷰

컨트롤러와 뷰의 연결은 대부분 아웃렛을 통해 이루어진다.

이 연결은 컨트롤러가 뷰에게 이야기하는 방식을 의미한다.

모델 <-> 뷰

모델과 UI는 독립적이므로 모델계층과 뷰계층에는 소통이 없다.

모델과 뷰의 모든 소통은 컨트롤러를 통해 이루어진다.

뷰 -> 컨트롤러

제한적이지만 뷰는 당연히 컨트롤러와 이야기할 필요가 있다.

?왜냐? 뷰는 컨트롤러의 하위종속자이고 UI안에서 일어나는 것들은 컨트롤러에게 무슨 일이 벌어지고 있는지 이야기해야하기 때문

따라서 뷰->컨트롤러의 의사소통은 눈에 보이지 않고 구조화되야함!

눈에 보이지 않는다? = 뷰에 있는 객체는 자기가 무슨 클래스에게 이야기하고 있는지 모른다!

• 예를들어 버튼같은 뷰는 뷰컨트롤러에 대해 아는 것이 없기 때문

구조화되야 한다? = 객체에 대해 아는 바가 없기 때문에 제대로 미리 서술되어있는 방식으로 의사소통을 해야한다!

<예시> 뷰의 하위종속자가 컨트롤러에게 이야기하는 구조화된 방식 - target-action 컨트롤러가 @IBAction코드로 메서드를 생성(타겟) 뷰의 하위종속자 객체를 컨트롤러가 생성한 타겟메서드와 연결하면 뷰가 컨트롤러와 이야기하고 싶을 때 간단하게 타겟메서드를 호출! 뷰로부터 컨트롤러로 보내지고 있는 액션은 보통 control + drag로 연결한다. + 가끔 뷰는 단순히 터치되는 것 이상으로 더 복잡한 의사소통을 하기도 한다. 예시) 뷰의 하위종속자인 스크롤 뷰 스크롤 뷰는 다양한 정보들을 컨트롤러에게 이야기한다. ?왜냐? 컨트롤러는 그것에 대해 알고 반응해야 하고, 정보가 모델에 영향을 줄 수도 있기 때문 따라서 주고받는 정보들이 많을 것이고 should, will, did 같은 말이 포함될 것이다. 뷰의 하위종속자들은 컨트롤러에게 다양한 질문을 하고 싶어하는데 이 질문들은 델리게이트라는 것을 통해 이뤄지게 된다. ?왜 Delegate(위임)일까? 뷰의 하위종속자들은 컨트롤러에게 어떤 책임을 위임하고 있기 때문! 델리게이트란 : 뷰안에 있는 프로퍼티 - MVC의 중요한 특성 뷰는 자신이 보여주고 있는 데이터를 소유할 수 없다. 뷰는 컨트롤러에게 매번 물어보고, 컨트롤러는 모델에서 데이터를 가지고 와서 표시한다. 이것은 다른종류의 프로토콜이다. should, will, did 대신 다른 프로토콜의 메시지를 받는다. 뷰는 데이터에 대해 이곳에 있는 데이터를 달라고하거나 데이터의 개수가 몇개인지 물어봐서 무슨 일이 생기고 있는지 알게되고, 그걸 화면에 보여줄 것이다. 이것 또한 델리게이션 과정으로 이루어 지는데 여기서 쓰이는 델리게이트를 dataSource라고 부른다. ## 모델 -> 컨트롤러 모델이 컨트롤러에게 이야기할 방법은 없다. ?왜냐? 컨트롤러는 UI로직을 다루고 모델과 UI는 별개이기 때문 하지만 UI와는 상관없는 모델이 값이 바뀌는 데이터를 가지고 있다면 모델은 라디오 방송국 모델을 이용하여 컨트롤러와 의사소통할 수 있다. 라디오 방송국은 모델이 자신의 방송국을 세우는 것으로 시작한다. 그리고 방송국으로 흥미로운 일들이 생길 때마다 방송을 한다. 그런 다음 컨트롤러는 그 방송국에 채널을 맞추어 놓는다. 그래서 모델은 컨트롤러에게 직접 말하지는 않는다. 그냥 모델에 무슨 일이 일어나고 있는지 알고 싶어하는 사람들이라면 그들에게 방송으로 말을 해준다. 모델에 의해 이루어지는 라디오 방송국안의 모든 소통은 UI와 관련이 없다. 단지 모델 안에 있는 데이터에 대한 것이다. [라디오 방송국은 모델과 컨트롤러 사이가 아닌 다른 계층 간에도 적용될 수 있다.]