[CHAPTER 2] MVC(Model-View-Controller) 패턴

MVC 모델

시스템내의 모든 객체들은 Model, View, Controller라는 세가지 캠프로 나뉠수 있습니다.

 

Model

앱에서 '무엇(What)'에 해당하는 UI와 독립적인 객체입니다.

Concentration 앱에서는 카드가 매치되는지, 카드를 언제 뒤집는지에 대한 내용이 있습니다. ( Concentration에 대한 지식 )

 

Controller

앱에서 '어떻게(How)'에 해당하는 객체입니다.

어떻게 Concentration 게임이 화면에 나오는지 관리합니다.

 

View

컨트롤러의 하인(Minions)입니다.

UIButton, UILabel등이 있습니다.

뷰에 나타낼 데이터를 인스턴스 변수로 가지고 있으면 안됩니다.

 

Controller -> Model 접근

컨트롤러가 원할때마다 언제나 커뮤니케이션이 가능합니다.

'무엇'이 어떤 것인지 사용자에게 보여주어야하기 때문입니다.

모델의 공개된 기능과 항상 접근이 가능합니다.

 

Controller -> View 접근

컨트롤러가 원할때마다 언제나 커뮤니케이션이 가능합니다.

예로 카드를 뒤집은 회수를 표시해주는 flipCountLabel의 Oultet이 있었습니다.

원하는 걸 대입하여 UI에 나타나게 할 수 있습니다.

 

Model  <-> View 접근

둘다 서로에게 접근이 불가능합니다.

모델은 UI와 독립적이어야합니다.

View는 UI와 관련된 것만 가지고 있어야합니다.

UI와 독립적인 모델과 UI에 의존적은 뷰는 서로 통신이 불가능합니다.

 

View -> Controller 접근

뷰가 컨트롤러에게 소통하는건 가능합니다.

하지만 뷰는 커뮤니케이션에 대해 아무것도 모르고 구조적이어야 합니다.

Concentartion에서 버튼(view)이 눌렀을때 처리할 함수는 지원하나 그것이 Concentartion과 연관되어 있는지는 모릅니다. 

Target-Action을 통하여 의사소통을 합니다. Ctrl + 드래그를 통하여 IBAction을 생성한 것과 동일합니다.

타켓은 Controller, 액션은 버튼의 특정 동작으로 볼 수 있습니다.

또한 Delegate를 통해 통신 할 수 있습니다.

스크롤 뷰를 통해 예를 들고 있는데, 스크롤뷰 안에는 델리게이트라는 변수가 존재합니다.

이를 통하여 스크롤 뷰가 스크롤했거나 줌을 했거나 했을시 델리게이트 변수(컨트롤러)에게 알려주게 됩니다.

컨트롤러에게 요청하기 위한 DataSource라는 Delegate도 있습니다.

테이블 뷰나 리스트뷰에서 가지고 있는 변수입니다.

해당 변수(컨트롤러)에 아이템의 개수나 섹션 수, 아이템을 어떻게 출력할지에 대한 로직을 요청하게 됩니다.

DataSource와 Delegate는 서로 비슷한데 제공하는 함수가 다르다고 보면 됩니다.

 

Model -> Controller 접근

직접적으로 소통은 불가능합니다.

Model의 상태값들이 변경되었을시 Controller에게 알리기 위해 라디오 모델을 사용합니다.

Notification, KVO(Key Value Observing)이 있습니다.

 

MVC -> MVC 접근

위와 같이 다른 MVC의 Controller를 View 계층으로 인식하고 접근해야합니다.

다른 MVC를 뷰의 일부분처럼 다룹니다.

세부사항은 모른채로 구조적인 방법으로 소통을 합니다.

일반적이고 재사용이 가능한 컴포넌트처럼 행동합니다.

이런 구조라면 나중에 관리하기 힘들어집니다.