2. 목차
1 What is Architecture?
2 MVC, MVP, MVVM 비교
3 Sample Project
4 느낀점
3. 1. What is Architecture?
Architecture
아키텍처 패턴(architectural pattern)은 주어진 문맥 안에서 소프트웨어 아키텍처의
공통적인 발생 문제에 대한 일반적인, 재사용 가능한 해결책을 의미한다.
참고 : 위키피디아 아키텍처 패턴
4. 1. What is Architecture?
개인 프로젝트 의사소통 필요 없이 혼자 규칙세워서 내맘대로
대규모 프로젝트
프로젝트에 대한 개발 언어, 구조 및 패턴,
역할 담당 등 다양한 세부적인 내용들을
규칙에 맞춰 협업하며 나눠야 함
5. 1. What is Architecture?
단순히 실행 가능한 코드
가독성이 떨어짐
코드의 역할이 불분명
유지보수에 굉장한 비용
6. 1. What is Architecture?
모듈을 역할별로 나누어 관리
모듈간의 관계를 유기적으로 형성
+
Architecture
Architecture
7. 1. What is Architecture?
좋은 Architecture
1. Balanced Distribution
객체간의 책임분리와 균형잡힌 분배
2. Testability
3. Easy of Use
테스트 가능 여부
적은코드, 유지보수에 좋음
8. 1. What is Architecture?
Distribution Category
Model View
Controller
Presenter
ViewModel
MVC
MVP
MVVM
+ +
9. 2-1. MVC
[ Problem ]
View와 Model의 의존성
1. View는 앱의 모양과 일관성 전달
2. Model은 도메인 관련 데이터 캡슐화 (Struct)
[ Solution ]
의존성 떨어뜨리고 높은 재사용성이 필요해!
기존의 MVC
10. 2-1. MVC
[ 기존 MVC Solution ]
View와 Model 분리
[ Problem ]
View와 Controller가 강하게 연결
대부분 View에서 반응하면 Controller로 보내짐
Massive View Controller
Apple’s MVC
12. + 단순하고 직관적, 작성하기 쉬움
- Controller가 매우 커짐 (Model에 넣기 애매한 건 VC에 몰빵)
- 너무 많은 역할을 담당 (Layout, 데이터 변환, 화면전환, 생명주기 ⋯ )
Apple MVC 공식문서
: 더이상 유효하지 않는 리소스
권고하지 않는 패턴 ?!
2-1. MVC
13. 1.Distribution
View와 Controller가 딱 붙어있어 분리가 잘 되어있진 않음
2. Testability
3. Easy of Use
분리가 잘 되어 있지 않기 때문에 테스트 어려움
간단하게 작성 가능, 입문자도 쉽게 접근
2-1. MVC
🧐 ViewController의 역할을 덜 수 없을까?
14. [Presenter]
뷰컨의 LifeCycle에 아무런 영향끼치지 않으며, View가 쉽게 테스트 가능한 복사본을 만듬
VC에서 꼭 처리해야하는 (생명주기, 화면전환, 콜백처리 등) 만 처리하고 나머지는 Presenter로 위임
오직 View의 데이터와 상태를 갱신하는 역할만
1 : 1 = View : Presenter
2-2. MVP
15. VC를 모아서 동작시키지 않고 분리해서 사용
But, Presenter와 View 간의 높은 의존성
View가 하는 일이 별로 없음
2-2. MVP
Presenter는 약한참조로 View를 소유
뷰에 직접 접근하여 업데이트
= 뷰를 업데이트 하는 소스가 Presenter에 속해있음
16. 1. Distribution
하나의 VC에 몰려있지 않도록 Presenter로 View 분배
2. Testability
3. Easy of Use
View를 재사용할 수 있어 테스트 가능
코드양이 2배로 늘었지만, MVC에 비해 재사용성 높아짐
2-2. MVP
🧐 Presenter와 View의 의존성을 줄일 수 없을까?
17. 2-3. MVVM
[ ViewModel ]
- 뷰 로직과 비즈니스 로직이 분리됨
- View와 Model 사이의 중개자 역할
- Model 데이터 가져오고, View가 쉽게 사용할 수 있는 형태로 가공해서 제공 (Presentation Logic)
19. 1. Distribution
ViewModel은 View를 알지 못하며 View 설정 코드가 전혀 없음
데이터 변경에 대한 View 업데이트는 온전한 View의 책임!!
2. Testability
3. Easy of Use
ViewModel은 View를 전혀 모른다 = 의존성이 없다 = 테스트에 용이
예제에선 MVP와 비슷한 코드량이지만 의존성 감소, 재사용성이 높아짐
2-3. MVVM
Massive ViewModel이 될 수도 있음
20. 2-3. MVVM
패턴에 정답은 없다
각각 패턴의 장단점을 잘 선택해 사용하는 것이 BEST!
어쨌든 MVVM 패턴은
Controller나 Presenter과 다르게
ViewModel은 View를
설정해주어야 하는 책임으로 자유
27. 3. Sample Project
Q. Entity 그대로 가져와서 사용하면 되지,
왜 Model을 따로 만들어서 사용하지?
같은 API를 쓰지만 전혀 다른 서비스
필요한 모델만 갖고와서 정확하게 명시
서비스 1 서비스 2
같은 API
a,b,c,d,e,f
a,b,d c,e,f
29. 3. Sample Project
ViewModel
: Service를 사용해서 Binding
Model -> ViewModel로 변경
* BehaviorRelay
직전의 값을 알아야할 때
Relay : UI 에 최적화
플젝 예제는 간단해서, model 값을
그대로 사용해서 binding 처리만 하지만
필요한 형태로 변경해서 값을 VM에서 바꿔줌
번외 ex) Model에서 받은 Date 타입을 View에 보이기 위해
String과 필요한 포멧으로 변경
31. 3. Sample Project
View
ViewModel
Service Repository
Model Entity
View는 Service 사용 Service는 Repostiory 사용
VM에 의존해서
화면을 그림
VM은 Service에 의존해
Model 가져옴
Model은 Repository로 부터 받아온
Entity를 이용해서 만들어냄
32. [ Before ]
개인 플젝만 해와서 솔직히 MVVM 패턴을 왜 쓰지?
많이 쓴다니까 써야하는데 굳이?
-> 필요성을 못 느낌
[ After ]
iOS Architecture Pattern 역사를 한번 훑게 되니
각 패턴들의 단점을 보안하기 위해 발전되었군!
즉, 의존성⬇ 재사용성⬆ 하기 위해 발전
나아가서 SwiftUI가 View와 ViewModel 간의
DataBinding을 property wrapper(@Binding, @State⋯)를 사용해서
MVVM 패턴과 잘 맞다고 하는데 공부해보면 좋겠다!
4. 느낀점
