Notice
Recent Posts
Recent Comments
Link
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |
Tags
- Tuist
- TCA
- Firebase
- iOS 개발자
- concurrency
- IOS
- composablearchitecture
- Alamofire
- SWIFT
- UI
- network
- xcodecloud
- iOS 13.0+
- ObjC
- tuist #xcodecloud #ios #ci/cd #swiftlint #firebase
- test
- Navigation
- xcode
- uikit
- SWIFTUI
- ios18
- 개발
- regex
- navigationsplitview
- Git
- 정규표현식
- swiftdata
- 모바일
- combine
- github
Archives
- Today
- Total
iOS 개발 기록
MVC, MVVM 본문
728x90
MVC 패턴과 MVVM패턴이란?
화면에 보여주는 프레젠트 로직과 실제 데이터가 처리되는 비지니스 로직을 분리하여 새로운 기능의 개발이나 유지보수에 용이하도록 사용하는 것을 목적에 둔다.
MVC
정의 : Model(애플리케이션의 정보), View(사용자 인터페이스), Controller(데이터와 비즈니스 로직 사이의 상호 동작을 관리)의 약자.
Model
- Model은 Data와 애플리케이션이 무엇을 할 것인지를 정의하는 부분으로 내부 비즈니스 로직을 처리하기 위한 역할을 한다.
- 모델은 컨트롤러가 호출을 하면 DB와 연동하여 사용자의 입출력 데이터를 다루는 일과 같은 데이터와 연관된 비즈니스 로직을 처리하는 역할.
- 데이터 추출, 저장, 삭제, 업데이트 등의 역할을 수행.
Mode의 규칙
- 사용자가 편집하기를 원하는 모든 데이터를 가지고 있어야 함.
- View나 Controller에 대헤서 어떤 정보도 알지 말아야 함.
- 변경이 일어나면, 변경 통지에 대한 처리방법을 구현해야만 한다.
View
- View는 사용자에게 보여주는 화면(UI)이 해당됩니다.
- 사용자와 상호작용을 하며 컨트롤러로부터 받은 모델의 결과값을 사용자에게 화면으로 출력하는 일을 합니다.
- MVC에서는 여러개의 View가 존재할 수 있습니다.
- Model에서 받은 데이터는 별도로 저장하지 않습니다.
View의 규칙
- Model이 가지고 있는 정보를 따로 저장X
- Model이나 Controller와 같이 다른 구성요소들을 몰라야 한다.
- 변경이 일어나면 변경 통지에 대한 처리방법을 구현해야함.
Controller
- Controller는 Model과 View 사이를 이어주는 인터페이스 역할.
- 즉, Model이 데이터를 어떻게 처리할지 알려주는 역할.
- 사용자로부터 View에 요청이 있으면 Controller는 해당 업무를 수행하는 Model을 호출하고 Model이 업무를 모두 수행하면 다시 결과를 View에 전달하는 역할.
Controller의 규칙
- Model이나 View에 대해서 알고 있어야 한다.
- Model이나 View의 변경을 모니터링 해야한다.
MVVM
- View와 Model은 MVC와 동일
ViewModel
- View를 표현하기 위해 만들어진 View의 Model
- Model의 정보를 View에 표시될 값으로 변환. 대체로 Class이므로 참조를 통해 반환.
- View와는 DataBinding을 통해 연결. Binding은 프레임워크단에서 제공, 보통 Rx나 Combine으로 구현
MVC와 MVVM의 차이
MVC | MVVM |
애플리케이션의 진입점은 컨트롤러 | 애플리케이션의 진입점은 뷰 |
컨트롤러와 뷰가 1:다수 관계 | 뷰와 뷰모델이 1:다수 관계 |
뷰에 컨트롤러에 대한 참조가 없음 | 뷰에 뷰 모델에 대한 참조가 존재 |
모델을 읽고, 변경하고, 단위 테스트하고, 재사용하기 어려움 | 복잡한 데이터 바인딩이 있는 경우 디버깅 프로세스가 복잡해짐 |
모델 컴포넌트를 사용자와 별도로 테스트 가능 | 별도의 단위 테스트가 쉽고, 코드가 이벤트 기반임 |
MVC | MVVM | |
장점 | · 단순하고 직관적임 · 기능 별로 코드를 분리하여, 하나의 파일에 코드가 모이는 것을 방지하여 가독성과 코드 재사용 증가 |
· View와 Model 사이의 의존성이 없음 : 유닛테스트 용이 · Command 패턴과 Data Binding을 사용하여 View와 View Model 사이의 의존성이 없음 |
단점 | · View와 Model 사이의 의존성이 높음 · 어플리케이션이 커질수록 복잡해지고, 유지보수가 어려움 |
· View-Model의 설계가 쉽지 않음 |
'Architecture, Design Pattern' 카테고리의 다른 글
Coordinator Pattern (0) | 2023.02.06 |
---|---|
Clean Architecture (0) | 2022.07.14 |
Clean Architecture - SOLID 원칙 (0) | 2022.07.14 |