[Swift/iOS] Swift 튜토리얼: MVVM 디자인 패턴의 소개(일부)

Swift Tutorial: An Introduction to the MVVM Design Pattern

Swift Tutorial: An Introduction to the MVVM Design Pattern

Swift Tutorial: An Introduction to the MVVM Design Pattern

(직역, 의역과 오역이 혼재되어있을 수 있으니 양해 부탁드립니다)

 

모든 프로젝트에서, 여러분은 어떻게 앱을 디자인하고 코드를 정리할지 정할 수 있습니다. 그러나 만약 당신이 주의를 기울이지 않거나 코딩을 서둘러 처리하기만 한다면, 그 코드는 스파게티처럼 꼬여버린 채 끝날 수 있는 위험이 있습니다. 해결책은? 적절한 디자인 패턴을 사용해야 합니다. 이 튜토리얼에서, Toptal 엔지니어인 Dino Bartošak는 데모앱에서 어떻게 MVVM패턴을 구현하는지 설명합니다.

여러분은 새로운 iOS프로젝트를 시작할 것이고, 필요한 모든 pdf와 sketch 문서들은 디자이너에게 받았습니다. 그리고, 여러분은 이미 어떻게 새로운 앱을 구현할지에 대한 비전이 있습니다.

 

여러분은 디자이너 스케치들로부터 받은 UI 화면을 .viewcontroller, .swift, .xib와 .storyboard 파일로 옮기는 것을 시작합니다.

 

그러나, UI요소에 다른 것을 할 때가 됐습니다. UIButton은 손가락 터치를 받고, UILabel과UITableVIew에는 어떤 포맷과 어떤 내용을 표시할 지 알려주는 어떤 것이 필요합니다.

 

갑자기, 당신은 3000 줄의 코드를 받았습니다.

 

이것을 해결하기 위한 첫번째 단계는, MVC 디자인 패턴을 적용하는 것입니다.

그러나 이 패턴은 문제점을 가지고 있고, MVVM 패턴이 당신의 시간을 절약할 것입니다.

 

스파게티처럼 얽힌 코드를 다루는 법

여러분이 만들기 시작한 ViewController는 순식간에 엄청나게 smart하고 massive하게 됩니다.

 

네트워킹 코드, 데이터 코드, UI 표시, 앱 상태 알림(notification), UI 상태 변경을 위한 데이터 설정 코드. 하나의 파일에 갇힌 모든 코드는 재사용 될 수 없고, 오직 이 프로젝트를 위해 맞춰지게 됩니다.

 

여러분의 ViewController 코드는 좋지 못한 스파게티 코드가 되었습니다.

 

어떻게 된 건가요?

 

적당한 이유는 이것과 같습니다.

 

여러분은 테이블뷰의 백엔드 데이터가 어떻게 동작하는지 아는 알기 위해서 서두르고 있습니다. 그래서, 뷰 컨트롤러의 임시 메서드 안에 몇 줄의 네트워킹 코드를 넣습니다. 그 다음에는 json 안의 데이터를 처리하는 것이 필요하게 되었습니다. 그래서 또다른 임시 메서드를 쓰거나, 심지어 더 좋지 않은 방법으로 같은 메서드 안에 하는 것입니다.

 

그 뷰컨트롤러는 유저 인증 코드가 따라올 때 계속해서 커졌습니다. 그 다음에 데이터 포맷이 바뀌고, UI가 변화하고, 근본적인 변화가 필요할때 여러분은 이미 거대한 코드에 계속 더 추가를 합니다.

 

어떻게 UIViewController는 통제 불가능하게 되었을까요?

 

그 UIViewController는 여러분의 UI 코드를 동작하는 논리적인 장소입니다. 그 컨트롤러는 여러분의 iOS 디바이스에서 여러분이 보는 어떤 앱을 사용하는 동안에 물리적인 스크린을 표시합니다. 심지어 애플은 UIViewController를 여러분이 다른 앱들과 움직이는 UI들 사이에서 전환할 때 메인 시스템 앱 안에서 사용합니다.

 

그것은 UI 코드의 핵심이고 MVC 파트의 부분이기 때문에, 애플은 UIViewController 안에서 UI 추상화를 기반으로 합니다.

 

MVC 디자인 패턴으로 업그레이드 하기

MVC 패턴에서, View는 비활성화 되어있고 오직 요구가 있을 때만 준비된 데이터를 표시합니다.

 

Controller는 data를 표시하는 view를 준비하기 위해서, Model data에 대해 작업해야 합니다.

 

Veiw는 유저의 터치 같은 어떤 액션에 대한 Controller의 알림에 대해서 책임이 있습니다.

 

언급한 것처럼, UIViewController는 보통 UI 스크린을 만드는 시작시점입니다. 그 이름에서 그것은 “view”와 “controller”를 포함한다는 의미라는 것을 주목해야 합니다. 이 의미는 ‘view를 control한다’라는 뜻을 의미하고, ‘controller와 view가 안에 있어야한다’라는 의미는 아닙니다.

 

view와 controller의 조합은 여러분이 뷰컨트롤러 안에 있는 작은 subView들의 UIOutlet을 움직일 때, 그리고 UIViewController로부터 직접 그 subView을 다룰 때 일어납니다.

 

이것이 View and Controller path들이 교차되게 이끄는 것을 보는 것은 어렵지 않습니다.

 

해결하기 위한 MVVM

여기가 MVVM 패턴이 편리하게 되는 지점입니다.

 

MVC에서 UIViewController는 Controller가 되기로 되어있고, 그것은 이미 View들과 많은 것들을 하고 있기 때문에, 우리 그것들을 우리의 새로운 패턴(MVVM)에서 View로 합칠 수 있습니다.

 

MVVM 디자인 패턴 에서, Model은 MVC의 Model과 같습니다. Model은 simple data를 나타냅니다.

 

Veiw는 .xib 파일과 .storyboard파일을 포함한 UIView와 UIViewController 객체들로 나타내집니다. 요소들은 오직 준비된 데이터를 보여주어야 합니다. (우리는 예를 들어 NSDateFormatter코드를 View안에 넣는 것을 원하지 않습니다.)

 

오직 ViewModel 로부터 온 간단하고 format된 string들만 있습니다.

 

ViewModel은 모든 비동기적 네트워크 코드, 시각적 표현에 대한 준비 데이터 코드, 그리고 Model의 변화를 listening 하는 코드들을 모두 숨깁니다. 이 코드들은 특별한 View에 맞게 만들어지고 잘 정의된 API 뒤에 숨겨집니다.

 

MVVM를 사용하는 것의 장점 중 하나는 테스팅입니다. ViewModel은 순수한 NSObject이고(또는 구조체), 그것은 UIKit 코드와 결합되지 않습니다. 여러분은 UICode에 영향을 미치는 것 없이 여러분의 unit을 좀 더 쉽게 테스트할 수 있습니다.

 

자 이제, ViewModel이 Model과 View사이의 풀처럼 작동하는 동안에 View(UIViewController, UIView)는 훨씬 간결해졌습니다.