[Architecture Pattern] MVC

아키텍쳐 패턴의 핵심은 "관심사의 분리(SoC)"이다.

"관심사의 분리"에 대해 잘 이해가 가지 않는다면 해당 포스팅을 참고 바란다.

[Architecture Pattern] SoftWare Architecture

UI Logic과 Buiness Logic은 특성도 다르고

UI Logic의 경우 자주 바뀌기 때문에 변경 주기도 다르다. 

따라서,  UI Logic과 Business Logic을 분리하기 위함이 MVC 패턴의 탄생 배경이다. 

 

 

MVC Architecture Pattern

MVC(Model-View Controller)는 

UI Logic과 Buisness Logic을 분리하고, 이들을 연결해주는 Layer로 구성된다. 

• Model : 데이터 관련 로직과 비즈니스 로직을 담당
• View : UI관련 로직을 담당
• Controller : Model과 View를 연결한다. (어떻게 화면에 표시할지)

 

기존의 MVC패턴은 Model의 변화를 직접 View가 감지할 수 있는 구조였다. 

즉, View와 Model이 서로 의존성이 존재하는 결합도가 높은 구조이다.

 

 

Cocoa MVC Architecture Pattern

Apple 에서는 View와 Model을 분리한 Apple's(Cocoa) MVC를 통해 재사용성을 높였다.

 

Cocoa MVC 패턴은 View와 Model을 분리하여,

View와 Model은 서로 직접 소통하지 않고 Controller를 통해 소통하게 된다. 

또한, Controller에는 Model에 구현하기 애매한 Buisness Logic을 구현한다.

 

View - Controller

Controller는 outlet을 통해 View에 직접적으로 접근할 수 있다.

class ViewController: UIViewController { // Controller
    @IBOutlet weak var tableView: UITableView!  // View
    ...
}

반면, View는 Controller에게 "delegate"를 통해 행위에 대한 요청과 

"data source"를 통해 데이터에 대한 요청을 할 수 있다.

즉, Protocol을 통해 DIP를 적용하여,

View는 Controller를 직접적으로 알지 못하는 구조이다.

대표적인 예시로 UITableView의 UITableViewDataSource, UITableViewDelegate가 있다.

 

또한, View-Controller는 

View의 action에 대한 target을 Controller에 구현하여,

View에서 발생한 action에 대한 처리를 Controller에서 처리한다. 

예를 들어 UITextField에서 작성을 완료하고 UIButton을 클릭하게 되면, 

클릭 Ac

 

Model - Controller

Controller는 Model에 직접 접근할 수 있다. 

반면, Model은 Notification & KVO를 통해 모델의 변화를 Controller에게 알린다.

 

 

UIKit Framework

UIKit Framework는 tvOS, iPadOs, iOS의 앱을 위한 Framework이다.

우리가 흔히 UITableView, UIViewController 등을 사용하기 위해서 import를 해줘야 한다.

 

이름에서 알 수 있듯이, UIKit은 User Interface와 관련된 것을 제공하고, 이벤트 처리를 제공한다.

이러한 기능들은 Core Object를 통해 제공이 되는데, 

Core Object도 MVC Pattern을 따른다.

 

UIKit 자체에서도 MVC 패턴이기 때문에,

접근성도 쉽고 애플에서도 앱 개발을 할 때 권장하는 패턴이다.

 

 

Pros & Cons

Pros

가장 첫번째로 UI Logic(View)과 Buisness Logic(Model)을 분리하여, 

Buisness Logic의 Test가 용이하다.

또한, UIKit도 MVC 패턴을 따르고 있고, 애플이 권장하는 패턴이기에 접근성이 좋다. 

마지막으로 간단한 패턴이기에 사용하기 쉽고, 빠르게 개발을 해야 할 때 유용하다.

Cons

Swift에서 ViewController는 View와 Controller가 너무 밀접하게 연관되어 있다.

Controller가 View의 Life Cycle까지 관리하기 때문에, 이 둘을 분리하기는 어렵다.

View와 Controller를 분리하기 어렵다는 것은

이는 재사용성이 떨어진다. 

 

두번째는 Controller만 테스트 하기 어렵다는 것이다. 

Business Logic을 소유하고 있는 Model은 분리되어 있지만,

Business Logic을 트리거하는 시작점인 Controller는

View와 밀접하게 연관되었기 때문에 Test하기 어렵다. 

예를 들어, 결제 버튼이 눌렸을 때, 제대로 사용자의 계좌를 조회하는지 확인해보고 싶다고 해보자.

이를 위해선 결제 버튼이 눌렸을 때, 해당 기능이 수행해야 되는지 체크해야 하지만,

이는 View를 띄우지 않고는 쉽지 않는 일이다.

 

마지막으로, ViewController는 Controller의 역할만이 아닌, 

View의 Life Cycle관리, Layout 등과 같이 View의 일부 기능도 떠맡게 된다.

이는 ViewController의 코드가 길어지게 되며,

이러한 의미에서 MVC를 Massive-View-Controller라고 하기도 한다.

 

Reference

위키피디아 

• 아키텍처 패턴
• 소프트웨어 디자인 패턴
• 모델-뷰-컨트롤러

Apple Documentation

• UIViewController
• Model-View-Controller
• About App Development with UIKit
• UIKit

 

https://medium.com/ios-os-x-development/ios-architecture-patterns-ecba4c38de52