티스토리 뷰

우선 본 글은

- MVC(Model-View-Controller)와 MVVM(Model-View-ViewModel)에 대해 .. 언뜻이라도 들어본 분들

- 그치만 잘 이해가 가지 않은 분들

- 무엇보다 iOS 개발을 (공부)하시는 분들

이 읽었을 때 가장 효과가 나타날 것 같은 글입니다

 

제가 잘못 알고 있는게 있다면 꼭 지적해주세요 ㅠㅠ!!

 

 

참고자료/출처이자 먼저 읽으면 좋은 글들

(전반적인 이해에 가장 큰 도움이 되었음)

 

[Introduction to MVVM]

www.objc.io/issues/13-architecture/mvvm/

 

Introduction to MVVM · objc.io

I got my first iOS job at 500px in 2011. I had been doing iOS contracting for a few years in college, but this was my first, real iOS gig. I was hired as the sole iOS developer to make the beautifully designed iPad app. In only seven weeks, we shipped a 1.

www.objc.io

[iOS 아키텍처 패턴(MVC, MVVM, VIPER)]

labs.brandi.co.kr/2018/02/21/kimjh.html

 

iOS 아키텍처 패턴(MVC, MVVM, VIPER)

Overview“글 한 번 써보실래요?” 입사하고 일주일이 지나 기술 블로그에 글을 써 보라는 제안을 받았습니다. 여러 고민 끝에, 아이폰 앱(이하 ‘iOS’) 주니어 개발자로서 프로젝트 경험과, 공부

labs.brandi.co.kr

위의 글들을 읽으셨을거라고 생각하며 ..

 

시작

 


잠깐의 사담

 

나는 지금까지 모두 MVC 패턴으로 개발을 했다.

웹에서 iOS로 넘어가면서 참여한 첫 프로젝트에서는 내가 프로젝트를 짰는데 완벽한 Massive View Controller 패턴을 만들어버렸다.

MVVM을 공부하면서 iOS에서 MVC를 좀 웃기게..? 말할 때 Massive View Controller라고 말하는걸 알았는데

저 단어를 보자마자 '이거 나잖아 ^^' 싶었다. 후..

 

새 회사를 오게 되면서 제대로 된 MVVM 패턴을 관찰하며 공부를 약간.. 좀 해봤고,

이전과 다르게 '와.. 나 좀 이해한 것 같아!!' 하는 행복하고 신선한 기분을 오랜만에 느껴서 이렇게 카테고리를 하나 잡고 글을 쓰게 됐다.

 

자주는 못 쓰더라도 이렇게 종종 내가 익힌걸 정리라도 해보려고 한다 ㅎㅎ

 

홧팅.

 

사담 끝.


 

 

 

위에서 언급했다시피,

나는 MVC가 익숙한 상태라 우선 왜 MVVM을 써야하는데 ?? 부터 납득해야했음

 

그럼 여기서 이어지는 질문으로

➡️  MVC의 단점이 뭔데 ??

In typical MVC applications, a lot of logic gets placed in the view controller. Some of it belongs in the view controller, sure, but a lot of it is what’s called ‘presentation logic,’ in MVVM terms – things like transforming values from the model into something the view can present, like taking an NSDate and turning it into a formatted NSString.

 

그래서 여기의 presentation logic을 분리하기 위해 만들어진게 ViewModel이다.

http://labs.brandi.co.kr/2018/02/21/kimjh.html

 

https://www.objc.io/issues/13-architecture/mvvm/

바로 이렇게 !

이게 iOS에서 MVVM 패턴에 해당한다.

 

➡️  그래서 ViewMdel 이 정확히 뭐냐면

In MVVM, you abstract your code to include a ViewModel, which is a file that holds the values to be presented in your view. The logic we write to format the value (i.e. formatting a string to be inserted into a UILabel) to be presented to the view takes place in the ViewModel.

 

 

Presentation Logic

= taking an 'NSDate' and turning it into a formatted 'NSString' 와 같은 작업

= formatting a string to be inserted into a UILabel 과 같은 작업

= View Model 이라는걸 알고 아래 설명을 다시 읽으면

 

"what MVVM is: an augmented version of MVC where we formally connect the view and controller, and move presentation logic out of the controller and into a new object, the view model."

 

갑자기 MVVM을 너무나도 잘 이해해버린듯한 기분이 들기 시작한다;

 

 

여기까지 이해했으면 MVVM의 여러 특성 중 가장 크게 납득이 가는 두 가지 특징은

  • MVVM works best with a binding mechanism.
  • Testable.

이렇게 두 가지가 되는데, 여기서 또 추가로 궁금해진 것은

왜 Testable 하냐?

➡️ 기존 MVC에서는 테스트 하려면 완벽한 ViewController와 View를 동반해야했고, 예를 들면 View의 label"의" value를 직접 검사하는 복잡하고, 불필요한 과정을 거쳐야했다. 그러나 MVVM에서는 이러한걸 ViewModel로 빼서, value 검사 시 View를 동반하지 않고!!

ViewModel.someValue

이런 식으로 단순히 꺼내오기만 하면 되니까 테스트가 수월해지는 것이다. = Testable하다!

 

If we hadn’t moved this logic into the view model, we’d have had to instantiate a complete view controller and accompanying view, comparing the values inside our view’s labels. Not only would that have been an inconvenient level of indirection, but it also would have represented a seriously fragile test. Now we’re free to modify our view hierarchy at will without fear of breaking our unit tests. The testing benefits of using MVVM are clear, even from this simple example, and they become more apparent with more complex presentation logic.

 

그럼 이제 지금까지 내가 이해한 MVVM 각 역할들을 정리해보자면

Model

: 일종의 Data Structure

(Struct 구조체. 그래서 프로젝트 코드를 보면 Codable을 썼던거였음.)

ViewModel

: 이제 Model과 여러 protocol들과 함께 이걸 View에 바로 보이게 / View에서 바로 쓰이게 할 수 있도록 presentation logic 역할을 한다!

View

: 보여주는 역할. iOS에서는 이걸 'View Controller'에서 하니까 사실상 MVVM에서는 View = VC(View Controller) 와 마찬가지가 됨.

(기존에 VC에서 하던 Controller의 역할이 어찌보면 ViewModel로 건너간거라, 완벽히(?) 분리가 되었으니 View = VC 라고 할 수 있지 않나? 싶다)

 

 

그럼 여기서 생기는 질문은

 

➡️ ViewModel과 Controller의 차이가 도대체 뭐지? 싶은거다.

왜냐면 내가 말한 것처럼 Controller의 역할을 ViewModel이 그대로 가져간거라고 한다면, MVC와 MVVM은 이름만 다른거잖아..

 

뭐지..?

 

싶은데 잘 생각해보면 iOS는 View와 Controller가 강하게 연결되어 있어 View Controller가 사실상 거의 모든 일을 한다

➡️ 사실상 그냥 View와 Controller가 VC라는 하나의 큰 몸을 갖고 있는거임..

 

따라서 애초에 정확히 M/V/C가 아니라 M/VC 였으므로

 

http://labs.brandi.co.kr/2018/02/21/kimjh.html
https://www.objc.io/issues/13-architecture/mvvm/

(이렇게!)

 

이거를 M/V/VM 이라고

VC를 View와 ViewModel의 역할로 완전히 분리시키고 VC 자체는 View의 역할만 하게

~ViewModel.swift 식의 ViewModel 파일을 만들어주는거다.

 

iOS는 Controller와 ViewModel의 차이로 구분지어

Controller ➡️ ViewModel 로의 전환? 변환? 이라고 생각하기 보다는

VC를 View, ViewModel 두 개로 나누어주었다고 생각하는게 이해와 정신건강에는 이로운 듯 싶다 ^^..

 

⇢ 여기까지 이해하고 RxSwift를 맛이라도 봤다면 .. MVVM 패턴을 왜 Reactive Programming(RxSwift 등)을 할 때 많이 사용하는 패턴이라고 하는지 정확하게 .. 이해하게 된다. 

 

 

느낀점 :

MVC의 ViewController에서는 Controller가 View의 Life cycle에 관여하기 때문에 View와 Controller를 분리하기가 어려웠다. 그래서 값을 update하려고 하면 예전엔 Observer를 등록하고 Noti를 보내서 update하기 or 억지로 타이머 걸기 등 그리 바람직하지만은 않은 방법을 총동원했었는데 (나의 경우) 엉망진창 패턴 + RxSwift와 RxSwift의 기능을 어느정도 직접 구현한 제대로 된 MVVM 패턴을 관찰하고 나니 급속도로 MVVM 패턴이 체득된 듯한 너무나도 기이하고 신선한 기분이 들었다.

 

  

댓글