일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
- Network
- withAnimation
- 네트워크
- dataflow
- arkit
- swift
- auth
- authentication
- iphone
- Animation
- state
- RxSwift
- ar
- stateobject
- environmentobjet
- GCD
- gesture
- Performance
- SwiftUI
- realitykit
- CS
- combine
- UIKit
- fullscreencover
- ios
- firebase
- 데이터최적화
- 달력
- Concurrency
- WWDC
- Today
- Total
XLOG
[아키텍쳐] MVC VS MVVM 의 간단한 정리 본문
프로그래밍을 하다보면 자연스럽게 아키텍쳐에 대한 고민을 하게된다. 고민의 이유는 너무 당연하다. 규모가 큰 프로젝트 구조를 잘 짜서 효율적으로 코드를 작성하여 효율적인 업무를 하고, 관리도 쉬워야 하기 때문이다.
가장 먼저 하고 싶은 말은' MVC, MVVM, MVP 등 어떠한 아키텍쳐가 좋다 라고 정답이 정해진건 아닌 것 같다' 이다. 진행하는 프로젝트의 규모, 진행하는 구성원, 주어진 시간 등을 고려하여 가장 효과적으로 진행할 수 있는 방법을 선택해야 하는 것 같다.
우선 MVC 에 대해 알아보자.
Model - View - Controller 의 약자이다. Model 은 데이터 모델, View는 화면, Controller는 중재자 같은 역할이다.
예를 들어 API를 통해 Json을 받아 우리가 필요로 하는 구조로 변경하는 것은 모델,
그런 요청, 입력 등을 받아서 모델에 전달해야하는 로직을 구성하고 View를 선언하는 것은 Controller,
사용자와의 Interaction을 담당하는 것은 View 라고 설명할 수 있을 것 같다.
View를 통해 유저는 Action을 발생시킨다. 그 Action을 View 는 컨트롤러에 전달, 컨트롤러는 그것을 확인하여 모델의 업데이트를 진행하고, 업데이트 된 내용을 모델이 뷰로 Notification을 준다. 가장 간단하고 직관적인 흐름인 것 같다.
UIKit 은 ViewController 가 있어서 인지는 모르겠지만 자연스럽게 MVC 패턴을 사용하게 되는 것 같다.
UIKit 을 공부해보면 알겠지만 MVC 에선 ViewController 1개는 N개의 View를 가지고 있을 수 있다. 또한 앱의 진입은 ViewController로 시작을 하게 된다. 프로젝트가 커질 수록 ViewController는 무거워지고 View와 Model의 의존성이 커진다. 의존성이 커진다는 것은 어느 하나에 문제가 발생하거나, 변화가 필요하게 되면 그 부분만을 고치는 것이 아닌 의존된 모든 코드를 수정해야할 수 있다.
그렇다면 MVVM 은 뭘까?
Model - View - ViewModel 이다. 가장 눈에 보이는 것은 Controller 대신에 ViewModel 이 들어갔다는 것이다.
ViewModel의 등장으로 조금씩 달라지는 것이 있다.
MVVM 을 채택한 대표적인 iOS Framework는 SwiftUI 이다.
MVC 와 달리 View는 여러개의 ViewModel을 가질 수 있다. 앱의 진입은 View로 진입을 하게 된다. View 에서 Action을 ViewModel에 전달하면, Model을 가지고 있는 ViewModel 은 모델을 업데이트 하여 View의 바인딩 되어 있는 데이터의 변경을 만들어 낸다. 바인딩 되어 있다는 Combine 을 의미하는 것 같다. 값의 변화가 발생하면 View의 그 변화를 알려 새로운 View를 render 하는. 아마 JS의 발전으로 React, vue 등 비동기 반응형 웹 프로그래밍 트렌드에 따른 앱에서의 패턴인 것 같다.
장점으로는 View와 Model에 의존성이 없으며, View와 ViewModel 과의 의존성 또한 없다(데이터 바인딩이기에). 그 얘기는 단위테스트에 용이하고, 코드가 이벤트 기반의 코드가 된다는 것이다.
의존성이 없고 단위테스트에 용이하기에 효율적으로 보이나 ViewModel의 설계가 어렵다는 단점이 있다.
View에서 여러개의 ViewModel을 가질 수 있다고 한 만큼 ViewModel 또한 View와 Model 에 성향에 따라 ViewModel을 따로 설계하여 단위테스트를 좋게 가져가야 하기 때문이다. 프로젝트를 진행하다 보면 ViewModel을 어디까지 작성을 해야할까에 대한 고민을 하게 된다.
MVC에서 MVVM 으로 넘어가는 추세인데 인터넷을 검색하다보면 MVC의 단점을 Model 과 View에 의존성을 얘기하며 MVVM 에 장점으로 의존성이 없고 단위테스트가 쉽다이다.
클린아키텍쳐를 더 공부해봐야 하지만 클린아키텍쳐도 각자의 역할에 따라 코드를 나누고, 서로의 의존성을 최소화 하고 일정한 흐름이 존재한다. 이는 결국 직관적이고 쉽게 코드를 이해하여 협업에 용이하고 프로젝트의 효율적인 업무, 관리를 목적으로 하는 것이다.
앞서 얘기한 것처럼 여기선 MVC 와 MVVM 에 대해 간단하게만 비교를 진행하였는데, 틀에 얽메이기 보단 왜 이 아키텍쳐를 채택했는데, 혹은 만들었는지 본인의 명확한 이유가 있다면 그것이 정답이지 않을까 싶다.
'Swift > Etc' 카테고리의 다른 글
[Swift] Async/await 의 이해 (0) | 2023.02.18 |
---|---|
[Swift] GCD 이해하기 (0) | 2023.02.16 |
[WWDC] Combine in Practice 보고 Combine 이해하기 (0) | 2023.02.02 |
[WWDC19] Introducing Combine (0) | 2023.02.01 |
[FirebaseAuth] Authentication (0) | 2023.01.30 |