RxMVVM-DataCenter is iOS app architecture to remove dependencies among ViewControllers. If you see the result which is made by using RxMVVM-DataCenter at https://github.com/skyfe79/RxGitSearch. You can know there is no dependencies among ViewControllers and how to use Rx techniques.
RxMVVM-DataCenter 은 어떻게 하면 의존성을 제거할 수 있을까에 대한 고민에서 시작된 프로젝트입니다. RxGitSearch라는 작은 예제를 만들어서 ViewController간에 의존성을 제거하였고 Rx를 사용하여 앱을 유연하게 변화에 빠르게 대응할 수 있도록 구현하였습니다.
Create App Easier With SVC Pattern - DroidKnights 2019 @SeoulBansook Nam
Suggest a new pattern "How to divide your Activity & Fragment".
Shows "Lotto - App" sample.
Youtube: https://www.youtube.com/watch?v=_-yZPjf9HLo
Hope it would help to understand Andoird Architecture Pattern.
RxMVVM-DataCenter is iOS app architecture to remove dependencies among ViewControllers. If you see the result which is made by using RxMVVM-DataCenter at https://github.com/skyfe79/RxGitSearch. You can know there is no dependencies among ViewControllers and how to use Rx techniques.
RxMVVM-DataCenter 은 어떻게 하면 의존성을 제거할 수 있을까에 대한 고민에서 시작된 프로젝트입니다. RxGitSearch라는 작은 예제를 만들어서 ViewController간에 의존성을 제거하였고 Rx를 사용하여 앱을 유연하게 변화에 빠르게 대응할 수 있도록 구현하였습니다.
Create App Easier With SVC Pattern - DroidKnights 2019 @SeoulBansook Nam
Suggest a new pattern "How to divide your Activity & Fragment".
Shows "Lotto - App" sample.
Youtube: https://www.youtube.com/watch?v=_-yZPjf9HLo
Hope it would help to understand Andoird Architecture Pattern.
1. 자바빈
[1995년] JAVA 탄생, 애플릿의강력함에매력
[1996년12월] Sun MicroSystems에서 자바빈1.0 명세발표, (자바를 위한 소프트웨어 콤포넌트 모델을 정의) 자바빈즈는 너무 단순했고, 개발자는 엔터프라이즈 개발자들은 좀 더 나은 것을 원함. 정교한 애플리케이션은 트랜잭션 지원, 보안, 분산컴퓨팅같은 서비스가 필요한데 반해 자바빈즈는 너무 단순함
[1998년3월] EJB 1.0 발표. EJB는엔터프라이즈급의 서비스를 제공하고 자바 콤포넌트의 사상을 서버측으로 확장했지만 원래의 자바빈즈가 가지고 있던 단순함은 잃어버림. 성공한 많은 애플리케이션이 EJB를 기반으로 구축되었음에도 EJB는본래 의도와 달리 엔터프라이즈 애플리케이션 개발을 단순화하지는 못함. 모든버전의EJB 명세에는“EJB는엔터프라이즈 애플리케이션의 작성을 쉽게 해준다” 라고 되어있다. EJB의 선언적 프로그래밍 모델이 트랜잭션, 보안과 같은 개발의 기반 구조의 여러 측면을 단순화했지만 배치설명자(Deployment Descriptor), 홈 인터페
이스, 원격인터페이스 등과 같은 과도한 코드를 기술하도록 함으로써 복잡성을 가중시켰고 시
간이 지날수록 개발자들은 환멸을 느꼈으며 결국 EJB 명성은 쇠퇴하기 시작했다.
<1탄>왜 마이크로 서비스인가 - 마이크로서비스로 구성된 애플리케이션 소개
Session abstract:
이번 세션에서는 무엇이 마이크로 서비스고, 어떤 철학과 사상을 가지고 있는지 알아봅니다. 세션이 종료되면 참석하신 분들은 마이크로 서비스의 구성에서 어떤 내용이 중요한지 알게 됩니다. 전체 시리즈로 진행되는 첫 세션 입니다.
Session agenda:
-실 서비스용 데이터베이스를 종료한다면 어떤 일이 벌어질까
-마이크로서비스와 마이크로서비스가 아닌것
-어떻게 시작해야 하나
-마이크로서비스 애플리케이션 소개
-클라우드 네이티브(클라우드 최적화란)
1. 자바빈
[1995년] JAVA 탄생, 애플릿의강력함에매력
[1996년12월] Sun MicroSystems에서 자바빈1.0 명세발표, (자바를 위한 소프트웨어 콤포넌트 모델을 정의) 자바빈즈는 너무 단순했고, 개발자는 엔터프라이즈 개발자들은 좀 더 나은 것을 원함. 정교한 애플리케이션은 트랜잭션 지원, 보안, 분산컴퓨팅같은 서비스가 필요한데 반해 자바빈즈는 너무 단순함
[1998년3월] EJB 1.0 발표. EJB는엔터프라이즈급의 서비스를 제공하고 자바 콤포넌트의 사상을 서버측으로 확장했지만 원래의 자바빈즈가 가지고 있던 단순함은 잃어버림. 성공한 많은 애플리케이션이 EJB를 기반으로 구축되었음에도 EJB는본래 의도와 달리 엔터프라이즈 애플리케이션 개발을 단순화하지는 못함. 모든버전의EJB 명세에는“EJB는엔터프라이즈 애플리케이션의 작성을 쉽게 해준다” 라고 되어있다. EJB의 선언적 프로그래밍 모델이 트랜잭션, 보안과 같은 개발의 기반 구조의 여러 측면을 단순화했지만 배치설명자(Deployment Descriptor), 홈 인터페
이스, 원격인터페이스 등과 같은 과도한 코드를 기술하도록 함으로써 복잡성을 가중시켰고 시
간이 지날수록 개발자들은 환멸을 느꼈으며 결국 EJB 명성은 쇠퇴하기 시작했다.
<1탄>왜 마이크로 서비스인가 - 마이크로서비스로 구성된 애플리케이션 소개
Session abstract:
이번 세션에서는 무엇이 마이크로 서비스고, 어떤 철학과 사상을 가지고 있는지 알아봅니다. 세션이 종료되면 참석하신 분들은 마이크로 서비스의 구성에서 어떤 내용이 중요한지 알게 됩니다. 전체 시리즈로 진행되는 첫 세션 입니다.
Session agenda:
-실 서비스용 데이터베이스를 종료한다면 어떤 일이 벌어질까
-마이크로서비스와 마이크로서비스가 아닌것
-어떻게 시작해야 하나
-마이크로서비스 애플리케이션 소개
-클라우드 네이티브(클라우드 최적화란)
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. 느낀점