[iOS] MVVM 패턴 알아보기 (vs MVC 패턴) (2)

오늘은, 이전에 포스팅 한 글에 이어서 MVVM 패턴에 대해 알아보려고 합니다.

앞서 알아봤던 MVC패턴과 어떤차이가 있는지를 확인하며 간단하게 정리 해보도록 하겠습니다.

 

 

※  글 작성시 잘못 된 내용이 있을 수 있습니다.

따라서, 잘못된 내용 지적해주시면 감사하겠습니다.!!

 

 

 

---

MVVM

MVVM패턴은 아주 훌륭한 디자인 패턴입니다.

Model과 View는 우리가 이미 알고있는 component인데, MVC와 다르게 

 

View Model라는 새로운 중재자가 등장합니다.

 

(사실 MVVM과 Apple's MVC 사에이 있는 MVP모델을 자주 비교하고는 하지만, 우리는 넘어가겠습니다.)

 

또한, 이미 알고있는 Model과 View의 역할도 조금 바뀌게 되는데, 이에 대해 알아보겠습니다.

 

 

 

1. Model

 

- Model은 데이터, 네트워크 로직, 비지니스 로직 등을 담습니다.

- View와 ViewModel의 구성과 변경에는 전혀 관여하지 않으며, 가지고 있을 Data만 다룹니다.

(사실 기존의 MVC에서의 Model과 크게 다를게 없는 것을 알 수 있습니다.)

 

 

2. View

 

- 사용자가 App을 사용 할 때, 실제로 화면에서 보이는 (UI)에 대한 layout, data표시등을 담당한다.

- Model과는 직접적인 연결이 이루어져서는 안된다.

 

그리고 MVC와 MVVM의 차이점 중 하나인, 

- View는 ViewModel에서 데이터를 가져와서 본인이 직접 View를 변경한다.

 

이를 위해 View는 ViewModel에게 데이터를 가져오게되고, 사용자의 interaction을 감지해서

이에 대한 처리를 ViewModel에 요청하게 됩니다.

 

 

3. ViewModel

 

- View에서 전달받는 요청을 처리하는 로직을 갖는다.

- Model에 변화가 생기면 ViewModel이 View에게 알려준다

• 데이터의 변화를 View에게 알려준다고 생각하면 됩니다

- 이처럼 View와 Model사이의 중재자 역할을 하며, Model의 데이터를 가져와서 View가 쉽게 사용할 수 있는 형태로

재 가공하여 제공해주는 Presentaion Logic을 갖습니다.

 

 

---

 

 

위에서 설명한 흐름을 하나의 동작으로 생각해보면,

 

1) View에서 event가 발생한다.

(ex 사용자가 버튼을 tap함)

2) View가 해당 이벤트가 발생했다는 사실을 ViewModel에 알려줌.

(ex View에 해당하는 VC에서 ViewModel의 특정 메서드를 호출 하는 방식으로 구현 가능 (꼭 이렇게 안 해도 됩니다!))

3) 변경 된 Data를 통해 Model을 새로 업데이트 한다.

4) Model이 변경되면 해당 Model을 소유하고 있는 ViewModel이 알게된다.

5) 또한, 해당 ViewModel과 bind되어있는 View가 업데이트 된다.

(View가 받아온 데이터를 가지고 스스로 UI를 업데이트 진행함)

 

정리해보면, Apples'MVC는 ViewController가 View를 변경하는 로직을 갖고 있는 동시에 LifeCycle을 관리하는 등

Massive 할 뿐 아니라, View와 상당히 밀접한 관계를 가지고 있습니다.

하지만, MVVM은 ViewModel을 View를 알 지 못하고 , View를 변경하는 로직을 가지고 있지 않습니다.

 

이를 통해, 각 View ViewModel Model이 더욱 독립적으로 사용이 되고 

유닛단위 테스트에서 상당히 용이한 측면이 있습니다!

 

 

---

 

 

MVVM 예제 코드

 

이론적으로는 이렇다는데, 예제 코드를 보면서 한번 확인 해 보겠습니다.

(해당 예제는 Reactive를 사용하지 않고 작성한 예제 코드 입니다. Rx를 사용한 예제는 이 곳을 참고해주세요!)

해당 예제 코드는 알파카님의 블로그에서 참고하였습니다!

 

2개의 TextField에 사람의 이름과 나이를 넣으면 Label에 표시되는 앱을 만들어 보겠습니다.

 

우선, Model을 보겠습니다.

struct Person {
    var name: String
    var age: Int
}

이름과 나이를 갖는 Person 구조체 입니다.

그 다음, Person을 표시 할 ViewModel을 만들어줍니다.

 

ViewModel

struct PersonViewModel {
    var person: Person
}

 

ViewContoller에는 UITextFieldDelegate의 메서드인 [textFieldDidEndEditing]을 통해서

textField에 변화가 일어나면 Lable에 뿌려주도록 하겠습니다.

extension ViewController: UITextFieldDelegate {
    func textFieldDidEndEditing(_ textField: UITextField) {
        guard let nameText = nameTextField.text,
            let ageText = ageTextField.text,
            let age = Int(ageText) else { return }
        
        personViewModel.person.name = nameText
        personViewModel.person.age = age
        
        yearLabel.text = nameText + " " + "\(age)세"
    }
}

이 상태에서 보면, [UI의 변화 -> ViewModel에 영향]의 과정을 가지고 있습니다.

즉 단방향으로 의사소통을 하고 있다고 보면 됩니다.

이것을, Property Observer를 통해 DataBinding을 하여 양방향으로 변경 해보겠습니다.

 

먼저, didSet을 통해 Model의 Person의 변화가 감지되면 변화된 Data를 Set해줍니다.

또한, Data변경의 Event가 발생할 때, 적절한 처리를 할 객체가 필요한데 Closure를 사용해 보겠습니다.

 

bind(lisenter: Listener?) 메서드를 통해서 외부에서 PersonViewModel의 Listener타입의 listner를 

지정할 수 있게 해줍니다.

 

ViewModel + DataBinding

struct PersonViewModel {
    typealias Listener = (Person) -> Void
    var listener: Listener?
    
    var person: Person {
        didSet {
            listener?(person)
        }
    }
    ...
    mutating func bind(listener: Listener?) {
        self.listener = listener
    }
}

 

이렇게 된다면, ViewController에서는 다음과 같이 바인딩을 진행하면 됩니다!

override func viewDidLoad() {
    ...
    personViewModel.bind { [weak self] person in
        self?.yearLabel.text = person.name + " " + "\(person.age)세"
    }
}

 

이를 통해서 textFieldDidEndEditing에서 Person이 변경되었을 때, 즉 ViewModel이 변경되었을 때

자동으로 yearLabel이 업데이트 될 것입니다.

 

이 뿐만 textField자체의 delegate를 사용하지 않고 DataBinding을 통해 로직을 직접 만들어서 수행할 수도 있습니다.

 

 

 

---

 

 

이렇게 MVVM에 대해 MVC와 비교하고, 간단한 예제를 통해 어떻게 코드로 적용하는지 알아봤습니다.

MVVM의 장점은 아주 다양한데, 몇 가지를 생각해보자면

1) ViewController가 가벼워 지거나

2) View나 ViewModel이 독립적으로 테스트 하기에 용이하다는 점 등이 있겠죠.

 

하지만 이런 MVVM에도 한계점은 명확합니다.

1) 간단한 프로젝트에 사용하기에는 MVVM이 과할 수 있습니다.

(바인딩, 의존성 주입과 같은 여러 작업이 필요할 수 있다.)

2) 바인딩에 대한 tool이 없으면 상용구 코드가 다량으로 발생합니다.

3) presentationLogic이 늘어나면 ViewModel이 비대해집니다.

(이건 모든 디자인 패턴이 다 그럴 듯)

4) Data Binding을 구현할 때, delegate pattern, closure등 상당히 다양한 방식이있다보니, 사람마다 MVVM을

구현하는 방식이 다 다르다

(MVVM을 처음 접하는 사람은 막막하다)

 

 

 

이렇게 MVVM에 대한 정리를 간단하게 해 보았습니다.

이상으로 글을 마치고, 읽어주셔서 감사합니다!

 

 

 

 

 

 

 

 

[참고 자료]

https://velog.io/@ictechgy/MVVM-%EB%94%94%EC%9E%90%EC%9D%B8-%ED%8C%A8%ED%84%B4

https://okanghoon.medium.com/rxswift-4-mvvm-with-rxswift-17a9b6d43746

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