아키텍처 패턴 (Architecture Pattern)
아키텍처 패턴은 공통적으로 자주 발생하는 문제를 재사용 가능하도록 패턴화한 것이다.
4대 아키텍처
현대에는 4개의 주요 아키텍처를 사용한다.
- MVC (Model-View-Controller)
- MVP (Model-View-Presenter)
- MVVM (Model-View-ViewModel)
- MVI (Model-View-Intent)
MVC 패턴
MVC 패턴은 모델(Model), 뷰(View), 컨트롤러(Controller)로 이루어진 디자인패턴이다.
뷰(view) 사용자 인터페이스
- UI 구성
모델(Model) 애플리케이션의 데이터
- data 저장
- 비즈니스 로직의 집합 (data 처리)
컨트롤러(Controller) view-model 사이의 중재자
- 사용자의 이벤트를 입력 받음
- view와 model에 대한 정보를 가지고 변경 이벤트를 받아 알려주는 역할 (view와 model은 서로를 알지 못함)
- 모델과 뷰의 생명 주기 관리
동작 방식
1) user event가 controller로 들어온다.
2) controller는 action을 확인하고 model을 업데이트한다.
3) model 업데이트가 완료되면 controller가 특정 view를 선택한다.
4) 해당 view는 model의 업데이트된 내용을 화면에 적용한다.
특징
- 개발 속도를 병렬적으로 가속화 시킬 수 있다.
- 여러 개의 뷰를 모델에 빌드할 수 있다. 비즈니스 로직과 데이터가 분리되어 있기 때문에 코드 복제가 제한된다.
- 변경사항이 전체 모델에 영향을 주지 않는다.
- 데이터를 어떠한 형태의 가공 없이 리턴한다.
- 뷰가 수정되면 컨트롤러도 함께 수정되어야한다.
MVP 패턴
MVC 패턴은 모델(Model), 뷰(View), 프레젠터(Presenter)로 이루어진 디자인패턴이다.
뷰(view) 사용자 인터페이스
- 사용자의 이벤트를 입력 받음
- UI 구성 (사용자에게 피드백)
모델(Model) 애플리케이션의 데이터
- data 저장
- 비즈니스 로직의 집합 (data 처리)
프레젠터(Presenter) view-model 사이를 중개
- view에게 사용자 입력을 전달 받아, model이 처리하도록 명령
동작 방식
1) view에서 user event가 들어오면, 해당 action이 presenter로 전달된다.
2) presenter는 model에 action에 따른 data 처리를 요청한다.
3) model에서 data 처리가 완료되어 data가 업데이트 되면, 업데이트 내역을 presenter로 전달한다.
4) presenter는 업데이트 된 내역을 화면에 적용할 것을 view에 요청한다.
5) view가 화면을 업데이트 함으로써 사용자에게 피드백이 제공된다.
특징
- MVP 패턴은 Presenter를 통해서만 데이터를 전달 받기 때문에 View와 Model 사이 의존성 문제를 해결하였다.
- 하지만 View와 Presenter가 일대일이 되며 어플리케이션이 복잡해질수록 둘의 의존성이 강해지는 문제가 발생한다.
- 어플리케이션의 디버깅을 더 쉽게 만든다. MVP는 세 가지의 다른 계층의 추상화를 소개하기 때문이다.
- 코드 재사용성이 높아진다. 뷰를 컨트롤 하기 위해 여러개의 프레젠터를 가질 수 있다.
- 더 나은 관심사 분리를 실행할 수 있다. 비즈니스 로직과 영속성 로직을 Activity와 Fragment 클래스에서 분리할 수 있다.
MVVM 패턴
MVVM 패턴은 모델(Model), 뷰(View), 뷰모델(View-Model)로 이루어진 디자인패턴이다.
뷰(view) 사용자 인터페이스
- 사용자의 이벤트를 입력 받음
- UI 구성 (사용자에게 피드백)
- view model을 통한 data binding을 이용하여 model 정보를 참조
모델(Model) 애플리케이션의 데이터
- data 저장
- 비즈니스 로직의 집합 (data 처리)
뷰모델(Presenter) view-model 사이를 중개
- view에게 사용자 입력을 전달 받아, model이 처리하도록 명령
동작 방식
1) view에서 user event가 들어오면, 해당 action이 command를 통해 view model로 전달된다.
2) view model은 model에 데이터 처리를 요청한다.
3) model은 데이터 처리가 완료되면 view model에 응답한다.
4) view는 옵저빙을 통해 view model을 관찰하고 있다가 model이 변경된 것을 감지하면 data binding을 통해 화면을 업데이트한다.
특징
- command와 data binding 두 가지를 사용하여 view와 view model 사이의 의존성을 없앴다.
- 뷰와 뷰모델 사이의 양방향 데이터 바인딩을 지원하며 UI를 별도의 코드 수정 없이 재사용할 수 있다.
- 테스트 용이성 : MVVM 아키텍처에서 각각의 모든 코드는 알갱이성(granular)을 유지한다. 적절한 방법으로 구현되었다는 전제 하에, 모든 내부적, 외부적 의존성을 코어 로직을 포함한 코드로부터 유지한다.
- 확장성 : 늘어나는 코드 알갱이 조각과 분리 경계로 인하여, 동시에 유지보수성을 얻게 된다.
- MVVM 패턴을 사용하는 가장 주요한 목적은 뷰를 추상화해서 비즈니스 로직 뒤에 있는 코드가 줄어들게 하는 것이다.
- 로직과 프레젠테이션 계층은 느슨하게 결합된다.
- 어설픈 UI 자동화 도구 없이 테스트가 가능하다.
*command: 여러가지 요소에 대한 처리를 하나의 액션으로 처리할 수 있게 하는 기법
*data binding: 화면에 보이는 데이터와 웹 브라우저의 메모리 데이터를 일치시키는 기법으로, 뷰모델을 변경하면 뷰가 변경된다.
'Programming > Architecture' 카테고리의 다른 글
SDK vs API (0) | 2023.04.11 |
---|---|
프레임워크(Framework) vs 라이브러리(Library) (0) | 2023.04.11 |
댓글