[iOS] 최고의 디자인 패턴, MVC 에 대한 오해

https://medium.com/flawless-app-stories/the-only-viable-ios-architecture-c42f7b4c845d

The only viable iOS architecture

 

MVC

Model 은 "data", View 는 유저가 보는 것, Controller 는 중개자 역할. Controller 는 Model 에서 데이터를 받아 View 를 통해 User 에게 보여주거나, User 의 동작을 View 에서 받아와 Model 에 전달한다.

 

언뜻 보기에, MVC 는 좋지 않아 보인다. Controller 가 해야 할 일이 너무 많기 때문. Controller 는 view hierarchy 를 관리하고 model 이나 view 의 logic 들을 일부 짊어 지기도 한다.

MVVM

MVC 의 불균형을 해소할 대안으로 MVVM 이 있다. ViewModel 이라는 새로운 계층을 두어 Controller 의 짐을 나누어 진다. 그런데 이것이 모든 문제를 해결하지는 않는다. ViewModel 에는 정확이 어떤 것이 들어가야 하나? ViewModel 또한 Controller 처럼 비대해진다면?

MVP

ViewController 를 View 로 취급하기 시작하고 모든 logic 이 Presenter 라는 새로운 계층으로 이동했다. 별로 인기 없고 이상해 보인다. 사실 모든 문제를 ViewController 에서 Presenter 로 옮긴 것 뿐 아닌가?

사실 MVC는...

MVC 의 문제들이 오해에서 비롯된 것 이라면 어떨까? 사람들이 MVC 를 오해하는 이유는 과도하게 단순화 시키려 하기 때문이다. MVC 는 pattern 도, 앱의 Module 분해를 돕는 scheme 도 아니다. 너무 많은 사람들이 각자 앱만의 문제를 MVC 로 해석하려 하기 때문에 MVC 에 대한 많은 오해가 생겨났다. MVC 는 어떤 앱에도 들어 맞는 만능 pattern 이 아니라 꽤 다양한 생각들에 기반한 개념이다.

 

MVC 는 일련의 구조적 생각들과 원리이다. MVC 는 앱이 GUI 와 함께 동작하는 방식에 대해 공식화하려는 첫 번째 시도인데, 이것의 주된 생각은 여전히 의미있고 iOS 에 한정된 것도 아니다. 그 원리 중 하나는 코드를 Presentation 과 Domain Model 로 분리하자는 것 이다. 

 

Domain Model 은 앱의 핵심이다. 이는 몇 가지 business objects(계좌, 상품, 거래 등) 로 이뤄져 있다. 이를 둘러싼 logic 을 business logic(계좌에 돈이 적은 사용자에게 할인을 적용하라) 이라 한다. MVC 의 Model 은 Domain Model 전체를 말한다. 이는 business logic 이 얼마나 복잡한지에 따라 객체 하나가 되거나 방대한 수의 객체 전체가 될 수도 있다.

 

Presentation 은 사용자가 직접 보고 상호작용 하는 대상 이다. MVC 에서 View(시각적 대상) 와 Controller(터치 등 상호작용) 모두 가 Presentation 의 일부라 할 수 있다.

 

Martin Fowler 는 이 원칙을 Separated Presentation 이라 불렀다. 이 원칙의 핵심은 domain object 와 GUI 간에 분명한 구분선을 긋는 것 이다. 이로 인해 Domain Model 과  Presentation 이 서로 독립된 상태가 된다면 앱의 디자인은 명료하고 재활용이 쉬우며 유지 보수 또한 용이할 것 이다. 

 

MVC 구조의 고안자인 Reenskaug 의 초기 보고서를 보면 Presentation 은 Domain Model 과 매우 약하게 연결되어야 하며 꼭 필요한 Interface 에만 의존하도록 되어 있다. 그리고 이 Interface Requirements 는 Facade pattern 을 통해 Domain Model 에서Presentation에게 전달된다. 

 

MVVM 혹은 MVP 역시 이러한 분리 원칙에 기반한 구조이다. 어떤 플랫폼 혹은 어떤 구조이건 간에 이 원칙을 지키는 것이 좋다. 고로, iOS 에도 역시 적용될 수 있고 중요하다는 뜻 이다.

 

한편, iOS SDK 에는 이미 UIView, UIViewController 가 구현되어 있는데 이는 MVC 가 이미 구현되어 있다는 의미이다. MVC는 패턴이 아니라 어떤 개념이기 때문에 상황에 따라 얼마든지 필요한 Class 를 만들 수 있어야 한다. 다만 UIView 와 UIVIewController 를 사용하는 한 당신은 이미 Apple 의 MVC 를 사용하는 것 이다. 한 마디로 MVC 는 우리의 선택이 아니다. (이미 사용 중인 것...?)

 

// Domain Model Object
struct Person {
    let name: String
    let gender: Gender
}
class ViewController: UIViewController {
    override func viewDidLoad() {
        super.viewDidLoad()
        // presentation logic 
        if person.gender == .male {
            nameLabel.text = "Mr." + person.name
        } else {
            nameLabel.text = "Mrs. " + person.name
        }
    }
}

 

위의 snipet 에서 presentation logic은 어디에 위치해야 할까. UIViewController 에는 이미 많은 복잡한 presentation logic 이 존재할 수 있고 심지어 test 하기도 쉽지 않다. 

 

Person class 에 넣어야 할까? presentation 과 business logic 을 뒤섞는 것은 분리 원칙에 위배된다. 정확히 어떤 View 에 보여질지도 불분명하고 만약 다른 내용 (이모티콘을 첨부하는 등) 을 추가 하고 싶은 경우에 재사용도 번거롭다. 

 

MVC는 고정된 pattern 이 아니기 때문에 존재하는 class에만 logic을 욱여 넣을 필요가 없다. 우리가 새로운 class을 작성하고 logic을 캡슐화하면 그만이다. Martin Fowler 는 만약 Domain Model Object 에 들어맞지 않는 어떤 데이터가 있다면 Presentation 계층에 새로운 Model 을 작성해도 된다고 한다. (이를 Presentation Model 이라 불렀다.)

 

struct PersonPresentation {
    let name: String
    init(person: Person) {
        if person.gender == .male {
            name = “Mr.” + person.name
        } else {
            name = “Mrs. “ + person.name
        }
    }
}

 

(사실 이는 MVVM 구조로도 불리는 형태이다. Presentation Model 은 ViewModel로 많이 불리고 있다. 하지만 사실은 이것이 어떤 완전히 새로운 형태의 디자인이 아니라 MVC 의 원칙으로부터 유연하게 변형된 계층이다. 즉, MVVM이라고 부를 수도 있겠지만 이건 MVC가 아니라 MVVM이야! 라고 말하긴 좀...? )