iOS - MVC 패턴

MVC (Model - View- Controller)

 

Model : 앱이 가지는 데이터들을 정의하고 비즈니스 로직을 갖고 있다.

 

View : 사용자에게 데이터를 보여주거나 UI를 담당한다.

 

Controller : Model과 View의 중간다리 역할. View로부터 사용자의 action을 받아 Model에게 어떤 작업을 해야 하는지 알려주거나, Model의 데이터 변화를 View에게 전달하여 View를 어떻게 업데이트할지 알려준다.

 

 

 

MVC 패턴에서 각 영역의 커뮤니케이션

 

Controller는 Model과 View에 직접 지시할 수 있지만 Model과 View는 Controller에 직접적으로 알릴 수 없다.

 

View에서 사용자의 action이 발생하였을 때 Controller에 알리는 2가지 방법

 

1. Controller는 View에서 발생할 수 있는 action에 대한 target을 만들어둔다.

-> View에서 유저의 action이 발생하면 Controller에 있는 target이 이를 받아들이고 작업을 수행

 

2. delegate 패턴의 delegate와 datasource를 이용하여 Controller에게 어떤 작업을 수행해야하는지 알린다.

 

 

Model의 데이터가 변경된 것을 Controller에 알리는 방법

 

Observer 패턴의 Notification과 KVO를 통해 Controller에 알린다.

Notification과 KVO는 일을 수행하는 객체(publisher)가 진행하던 작업이 끝나면 자신들을 구독중인 객체들(subscribers)에게 신호를 보내는 방식이다. 

 

 

MVC 패턴의 장단점

장점

• 다른 패턴에 비해 코드량이 적다.
• 애플에서 기본적으로 지원하는 패턴 -> 쉬운 접근성
• 많은 개발자들에게 친숙한 패턴
• 개발 속도가 빠르기 때문에 아키텍처가 중요하지 않을 때 사용하거나 규모가 적은 프로젝트에서 사용하기 좋다.

 

 

단점

View와 Controller가 너무 밀접하게 연결되어 있다. ViewController처럼 View와 Controller가 붙어 있으며, Controller가 View의 Life Cycle까지 관리하기 때문에 View와 Controller를 분리하기 어렵다. 이렇게 되면 재사용성이 떨어지고, 유닛 테스트를 진행하기 힘들다. 또한 대부분의 코드가 Controller에 밀집될 수 있다. Life Cycle 뿐만아니라 delegate나 datasource 관리, 네트워크 요청, DB에 데이터 요청 등 많은 코드가 Controller에 작성되면 Controller의 크기는 비대해지고 내부 구조는 복잡해진다. 복잡해진 코드는 프로젝트 규모가 커질수록 유지보수를 힘들게 한다.

 

 

[참고 : https://velog.io/@zooneon/iOS-MVC-%ED%8C%A8%ED%84%B4%EC%97%90-%EB%8C%80%ED%95%B4-%EC%95%8C%EC%95%84%EB%B3%B4%EC%9E%90]