Design Pattern
- 디자인 패턴을 정하게 되면 모든 클래스와 속성을 구조적으로 정리가능하며 팀 작업 시 원활한 의사소통과 코드 수정이 가능하다.
❗️ MVC(Model-View-Controller)
- 오리지날 MVC 패턴은 iOS 개발에 적합하지 않아(Model,View,Controller 가 너무 밀접하게 연관) 애플에서는 CocoaMVC 패턴을 제시했다.
- View 와 Model 사이에서 중재하는 역할
- 사용자가 입력받은 데이터를 View 와 Model 에게 전달하는 것도 담당
- Controller 가 View 와 Model 의 중재자 역할을 하여 View 와 Model 에 독립성 부여
- 스토리보드에서 화면을 짜고 서버나 로컬 DB 에서 받아온 데이터를 이리 저리 알맞게 다듬어 view controller 에서 storyboard 에 연결된 label, imageview 등에 적용시키는 작업을 해봤다면 이 패턴의 구조를 쉽게 이해할 수 있을 것이다.
- Model : 데이터에 관한 로직 담당(데이터 값 변경 및 관리)
- View : 사용자에게 보여지는 화면 담당(UI)
- Controller : Model 과 View 연결(Model 값을 View 에 보여줌)
- Model - View - ViewModel
MVC 장단점
장점 : 비교적 간단한 패턴으로 구조파악과 확장을 쉽게 할 수 있습니다.
단점 : 뷰와 모델의 완벽한 분리가 어렵고 앱이 커지면 컨트롤러의 코드량이 커져 유지보수 하기가 힘듭니다.
iOS개발이 MVC에서 MVVM으로 넘어가는 이유
기존에 많이 사용한 UIKit 프레임워크는 MVC 패턴을 기반으로 만들어졌음
최근에 나온 SwiftUI는 MVVM 패턴을 기반으로 함
UIKit에선 ViewController가, SwiftUI에선 View가 주인공
UIKit에서는 ViewController가 거의 모든 역할을 하고 있고, VC단위로 화면들이 구성되어 있다. Controller는 View,Model 계층을 모두 소유하고 있으며 Model의 notification도, View가 유저 상호작용을 전달하는 방식도 모두 delegation을 통해 VC이 다 떠맡고 있다.
SwiftUI에서는 View가 ViewModel을 소유하고, ViewModeldl Model을 소유하는 방식이다. Controller 단위로 화면을 구성하는 것이 아니라, 해당 화면을 주도하는 것은 View다. 따라서 View와 Model을 모두 알고 있어야하는 Controller와 달리, ViewModel은 View에 대해서는 알고 있을 필요가 없다.
❗️ MVVM(Model-View-ViewModel)
- MVC 패턴의 Controller 가 커지는 문제를 View Model 을 둠으로써 해결하고자 한다.
- ViewModel 을 항시 주시하여 ViewModel 에서 데이터가 바뀌면 데이터 바꿈
- 데이터를 관리하는 Model 에 변화가 생기면 이는 ViewModel 에게 자동으로 notify 되고, ViewModel 과 사전에 binding된 View가 업데이트 된다. 반대로 View로 어떠한 이벤트가 들어오면 이는 ViewModel에게 알려지고, 이를 감지한 ViewModel은 Model의 내용을 수정한다.
- Model 에서 가져온 View 에 업데이트할 데이터를 View Model 이 처리하게함으로써 Controller 가 복잡해지는 것을 줄여준다. 즉, View Model 은 presentation logic 을 다루게 되지만 UI 는 다루지 않는다.
Model
- 데이터와 관련된 코드를 담고 있는 계층 (MVC의 Model과 마찬가지)데이터를 담아두기 위한 구조체들(struct)
- 네트워크 로직 JSON 파싱 코드
View
- 앱의 UI에 대한 코드를 담고 있다. ViewModel로부터 데이터를 가져와 어떻게 배치할지, 특정 상황에 따라 ViewModel의 어떤 메소드를 이용할지도 담고 있다.
- View는 재사용성이 강조되며, 컴포넌트를 적당히 잘 나누어 중복된 코드를 줄이는 것이 중요하다.
View Model
- Model 과 View 의 중개자. View Model 은 View 의 상태를 저장하고, View 에서 발생하는 액션에 따라 수행할 앱의 기능을 정의하는 명령을 구현. View Model 은 View 가 어떤 모습인지 전혀 알지 못한다.
MVVM 장단점
- 장점 :
- View 가 ViewModel 에 있는 데이터를 실시간으로 관찰한다. -> Observable 패턴을 사용하여 DB 관찰하고 자동 UIView 를 업데이트한다. 직접 View 를 바꾸지 않아도 된다.
- LifeCycle 를 따르지 않는다. -> 메모리 누수 방지 화면전환 같은 경우 화면을 없애서 재구성돼도 ViewModel 이 데이터를 가지고 있어서 서로 영향 X
- 코드의 가독성이 높아진다.
- 단점 : ViewModel 설계가 어렵고, View 에 대한 처리가 복잡해질수록 ViewModel 이 오버스펙이 될 수 있다.
MVC VS MVVM
가장 큰 차이점은 컨트롤러의 역활을 나눈 것에 있습니다. 앱이 커질수록 컨트롤러의 코드가 길어지기 때문에 줄이기 위해 역활을 나누었습니다.
- MVC의 Controller
- 사용자의 이벤트에 따라 모델 객체를 변화시킴
- 사용자의 이벤트에 따라 뷰를 변화시킴
- MVVM의 Controller
- 사용자의 이벤트에 따라 뷰를 변화시킴
🔎User 상호작용이 일어났을때.. (예: 버튼 누름)
MVC : user 상호작용이 일어났음을 View → Controller로 알림 & 그에 따라 어떤 행동을 할지는 Controller가 정함
MVVM : 어떤 행동을 할지는View가 정함. ViewModel은 로직만 가지고 있음
🔎데이터가 변경되었을때.. (예: 버튼 누름)
MVC : 데이터의 변경이 일어났음을 Model → Controller로 알림 & 그에 따라 View를 다시 어떻게 그릴지는Controller가 정함
MVVM : 데이터의 변경이 일어났음을 Model → ViewModel로 알림 & ViewModel은 변경사항을 바로 View에게 전달하는 역할만 하고,View가 알아서 다시 그림
코드 차이점
'App Dev' 카테고리의 다른 글
[IOS] CRUD in swift _ CoreData (0) | 2022.12.02 |
---|---|
[iOS] 동기 및 비동기 (0) | 2022.11.28 |
[IOS] IOS 앱 생명주기 (0) | 2022.11.24 |