[ Architecture ] MVC 패턴

 

🔎  1 . Model, View, Controller

---

Model

데이터와 비즈니스 로직(화면과 관련이 없는 로직과 데이터 관련)

Model의 데이터가 변경되면 Controller에 알리기 위해 KVO, Delegate 패턴, Notification Center 등을 사용한다.

예를 들면, 사용자 정보를 저장하고 불러오는 클래스나 구조체가 여기에 해당한다. 

 

view

뷰컨트롤러의 명령을 받아 UI 요소들을 사용자 화면 표시하는 사용자 인터페이스 담당.

view는 Model에서 데이터를 받아와 사용자에게 보여주는 역할이다. 

 

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

예를 들어, 사용자가 버튼을 클릭하면 View는 해당 이벤트를 Controller에 전달한다.

View에서 유저의 action이 발생할 경우 Controller에 있는 target이 이를 받아들이고 작업을 수행한다.

 

또한 View는 delegate 패턴의 delegate와 datasource를 이용하여 Controller에게 어떤 작업을 수행해야하는지 알리기도 한다.

대표적인 예로 UITableView의 UITableViewDelegate와 UITableViewDatasource를 들 수 있다.

 

 

controller

Controller는 사용자 입력을 받아 Model을 업데이트하고, Model의 변경 사항을 View에 반영한다. 

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

 

 

 

 

 

 

🔎  2. MVC 패턴의 단점

---

 

강한 결합도 (Tight Coupling):

Controller가 View의 Life Cycle까지 관리하기 때문에 View와 Controller를 분리하기 어렵다.

이는 독립적인 테스트와 재사용이 어렵다.

UI 변경 시 Controller 수정을 해야 하고, 비즈니스 로직 변경 시 View 수정을 해야 할 가능성이 크다.

 

 

유지보수성 감소 (Reduced Maintainability):

코드가 커지면 Controller에 많은 기능이 집중되면서 코드의 복잡성이 증가한다. 이는 유지보수와 디버깅을 어렵게 만든다.

 

 

재사용성 문제 (Reusability Issues):

View와 Controller의 강한 결합으로 인해 View를 다른 프로젝트나 다른 부분에서 재사용하기 어렵다.

다양한 View가 동일한 Controller를 사용하는 것도 힘들다.

 

 

Massive View Controller (MVC Anti-pattern):

많은 코드가 Controller에 집중되어 Controller가 비대해지고 복잡해진다. 이는 프로젝트 규모가 커질수록 유지보수를 어렵게 만든다.

이러한 문제를 해결하기 위해 View와 Controller 간의 결합도를 낮추고, 각 컴포넌트의 책임을 명확히 분리하는 것이 중요하다.

Delegate 패턴, Notification Center, KVO 등의 방법을 사용하여 개선할 수 있다.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

🔗 Reference 

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