MVC Pattern

📖 MVC Pattern(Model-View-Controller)

Model + View + Controller 구조의 아키텍처 패턴

• 하나의 View는 하나의 mvc로 제어
• MVC와 MVC가 소통할 때 다른 MVC는 항상 자신의 View로 취급
  즉, 어떤 MVC는 다른 MVC의 View가 될 수 있음

📖Model

어플리케이션의 데이터와 비즈니스 로직을 담당

• View에 대해선 몰라 그냥 데이터만 관리하는 객체 → 받아온 데이터를 그에 맞춰 저장할 형태를 만드는 것이 중요, UI에서 어떻게 보일지는 신경쓰지 않음(Person이라는 구조체에 생일을 저장하는 것은 OK, 문자열을 어떤 식으로 파싱해 어떤 식으로 화면에 띄울지는 NO)
  
• 데이터로 사용하는 구조체(새로운 데이터 추가/기존 데이터 정보 업데이트/특정 데이터 정보 얻기)
• 네트워크 로직 : 네트워크 요청을 하고, 그 결과를 받아오는 기본적인 기능을 담은 네트워크 로직
• 데이터 파싱 : JSON 등의 데이터가 왔을 때 파싱하는 로직
• Manager 객체 : 구조체를 만들어두고 필요한 경우 어디서든 접근해 사용할 수 있도록 Manager를 따로 만드는 경우

📖View

사용자 화면 표시(UI) 를 담당

• 직접 유저와 상호작용
• 재사용성이 강조
• 화면 표시에만 관심 있어 Model에 대해선 몰라
  
• UIView를 상속해 만들어진 서브클래스
• Core Animation
• Core Graphics

📖Controller

Model과 View의 중재자 역할을 담당

• 앱의 핵심 로직을 담고 있는 계층(모델아 너 이 함수 실행해, 뷰야 너 화면 이렇게 바꿔)
  
• Model의 정보를 해석하고 구성해서 View를 어떻게 업데이트를 해야 하는지를 알려줌
• View에서의 사용자와의 상호작용을 해석해 Model이 어떤 작업을 해야 하는지를 알려줌

📖Apple의 MVC

View Controller가 View와 Controller의 역할을 모두 수행 즉, View Controller가 View와 Controller를 관리하고 연결해주는 역할

📖MVC Pattern에서 각 영역이 대화하는 방법

📎Controller → Model/View

• Model에 직접 접근 가능
• View에 대해서 직접 접근 가능(outlet)

📎View → Controller

• target-action 구조로 사용자의 행위(in View)에 따라 필요한 함수를 호출(in Controller)
• delegate, datasource를 통해 미리 정해진 방식의 요청을 수행

📎Model → Controller (directly : NO indirectly : YES)

Model UI(View)와 독립적이고, Controller는 근본적으로 UI(View)에 종속되어 있기 때문에직접적으로 상호작용하지 않고 Controller를 통해 간접적으로 상호작용

• Model이 Notification을 이용해 무언가 변화했다는 신호를 보내두면, 나중에 Controller가 그 알림을 보고 다시 Model에 접근해 새 데이터를 받아옴
• Model에 있는 프로퍼티에 Controller가 KVO(Key-Value Observing)을 이용해 그 프로퍼티의 변화를 감지해 새로운 데이터를 받아옴 → Model은 이미 알려져있는 주파수로 방송, Controller는 그 주파수에 맞추고 있다가 모델의 방송에 달라진 게 있으면 Controller가 Model에게 가서 바뀐 데이터를 가져오는 식(like radio)

📖MVC Pattern의 장점

• 서로 역할을 나누어서 구현하기 때문에 가독성이 좋음
• 접근이 쉬워 유지보수가 용이
• 개발 속도가 빨라 규모가 작은 프로젝트에서 사용하기 좋음

📖MVC Pattern의 단점

• View와 Controller가 너무 밀접하게 연결 → 대부분의 코드가 Controller에 밀집될 수 있음
• 프로젝트가 커질수록 유지보수가 힘듦