[아키텍처 패턴] MVVM + Clean Architecture 공부 정리

학습 목표

• MVC, MVP, MVVM 각각의 특성
• Clean Architecture (VIPER Architecture)
• MVVM + Clean Architecture

---

학습 내용

MVC, MVP, MVVM

MVC 패턴

• UIKit 기본 구조 역할에 따라 구분됨
• Model - 데이터 관리 View - 화면(UI) 관리 Controller - 컨트롤 관리
• VC가 Input 받고, Input 처리하고, 처리에 따른 View도 변경.. → 하는 일이 너무 많음

MVP 패턴

화면과 로직을 분리함

• MVC에서 View에 VC가, C에 Presenter가 들어감
• MVP 패턴도 MVC와 같이 Model-데이터, View-화면관리, Input 관리
• View는 Input이 들어오면 Presenter에 알려야 함 → P는 로직처리 후 어떤 화면을 그릴 지 알려줌
• Presenter - 로직 처리와 화면 그리는 역할은 하되, UI 관련 로직은 포함 X

단점

: View-Presenter가 1:1 이기에 View마다 Presenter 생성

MVVM 패턴

• MVC에선 Controller가 View와 Model 일을, MVP에선 Presenter와 View가 서로 일 주고받음
• MVVM에서 ViewModel은 Model하고만 소통함 화면처리 = 알빠노 ?
• VM= Model로부터 데이터 가공, 로직처리
• View는 ViewModel을 구독하고 있음 → ViewModel이 바뀐걸 보면 View가 지 화면 새로 고침
• 여러 화면이 있더라도, 비슷한 데이터를 처리한다면 ViewModel은 1:N 관계

MVVM에서 import UIKit을 권장하지 않는 이유

→ View → ViewModel의 단방향 흐름이 깨지기 때문

→ 그러나, 항상 원하는 대로 흘러가는 것 같지 않음

Clean Architecture (VIPER)

도메인 영역 (Entity)

사업 자체가 바뀌지 않는 한 동일한 영역 어떤 데이터가 DB에 있고, 그 DB에 있는 데이터를 가공해서, 어떤 로직에 의해 계산할지..

• Model
• Service 원천이 되는 데이터로, 바뀌지 않는 데이터
• Business Logic
• 데이터를 가공하는 로직, (Model보다 상위에 있음) 여기도 바뀌지 않는 내용으로 주로 이 계층을 가지면 회사 정책과 관련된 부분

비영속성 지역들

• ViewModel (Interactor)도메인 영역과 View의 중간 다리 역할을 함 → Interactor 라고 불림
• MVVM의 ViewModel은 View와 1:N 관계였음 ViewModel은 여러 뷰를 담당, 즉 ViewModel이 가진 데이터는 특정 화면을 위한 데이터가 아닌 공용 데이터
• 도메인을 가공해서 화면에 보여줄 수 있게 처리하는 역할
• PresenterViewModel이 공용 데이터를 담당했다.하나의 View를 담당하게끔 Presenter 도입
• 그럼 각각 View에 맞는 화면에 필요한 로직은 공용 데이터를 관리하는 VM에서 작성될 필요가 없음
• 특정 화면에서 데이터를 가공해 보여줄 필요가 있다면.
• View
• 화면을 보여주는 역할
• Coordinator (Routing)
• 네비게이션 처리 (Routing) 역할을 함

위 요소들의 이름 앞글자를 따서 **V**(iew)**I**(nteractor)**P**(resenter)**E**(ntity)**R**(outer) 라고 부름

<aside> 💡 꼭 VIPER가 아니어도, 위와 같은 로직 각자 역할을 잘 수행하면 변경되는 요소가 어디인지에 따라 유지할 수 있는 범위가 정리되고 제한됨

</aside>

• Entity - 서비스가 바뀌지 않으면 영원히 변경되지 않는 부분
• Interactor - 화면이 변경되든 말든 알빠노, 공용 데이터 처리
• Presenter - 디자인이 바뀌지 않는 한 바뀌지 않는 부분, 하나의 View를 담당

Clean Architecture는 변화가 발생했을 때, 어디까지 안전하게 지킬 수 있는가를 구조화한 것

원 바깥에서 일어나는 일은, 안쪽에 영향을 주지마라

MVVM + Clean Architecture

💡 서버에서 오늘 날짜 데이터를 갖고 와서, 화면에 보여주는 예시를 통해 학습

1. 서버에서 받아온 JSON 중, currentDateTime은 String 타입
2. 위 JSON 형식을 TimeModel 구조체를 만들어 변형해야 함 (String 타입)
3. TimeModel 구조체를 갖고와서 Date 타입으로 변환
4. Date 타입을 UILabel에 표시하려면 다시 String으로 변환

모델 정의

ViewModel

화면에 보여주기 위한 처리 String 타입

Model

Date 타입, 실제 데이터

TimeModel (Entity)

서버, DB 모델 JSON = String 타입

Entity가 로직에서 취급하는 Model이 되고, Model이 ViewModel로 가공되어 화면에 보여짐

그럼 이런 Model들은 어떻게 동작하는가 ?

각 Model은 누가 구성하고, 어떻게 동작하는가 ?

서버로부터 데이터를 Fetch 하는 건 Repository 영역이 담당함 즉 Repository의 결과물이 Entity

Repository

• 서버에서 Entity를 Fetch 함
• Entity를 전달하는 메소드를 지님

Entity Model

• struct 형태의 모델
• 서버에 저장된 데이터의 형태

Mapper

• Entity로부터 Model을 만들어냄

Model

• 서비스에 사용되는 데이터 모델
• Mapper가 가공한 결과물

Logic

• Model을 갖고 로직을 수행함

ViewModel

• View를 위한 Model
• View에 보여질 데이터는 Model이 아닌, ViewModel에서 가공해야 함

View

• ViewModel에 의존하는 영역으로, ViewModel이 변경되면 View는 화면 세팅

MVVM 관점으로 정리

위처럼 구성될 경우 비즈니스 로직은 VM이 아닌, Logic에 있음

화살표를 통해 의존성을 잘 볼 것

1. View의 viewDidLoad() 호출
2. View는 ViewModel에게 데이터를 요청함
3. ViewModel은 Logic 영역에 데이터를 요청
4. Logic은 Repository 영역에 데이터 요청
5. Repository를 통해 Entity가 들어오면 Entity를 Mapper해서 Model로 변경 + Logic에도 보내주게 됨
6. ViewModel은 Logic에서 반환한 Model을 ViewModel로 가공해서 View가 추적할 수 있게 해줌
7. View에 ViewModel이 올라가고, trigger 함

다른 아키텍처에서는 ?

MVC 패턴

Controller가 View, Domain, .. 다 접근함

MVP 패턴

Presenter가 View에게 간섭

정리

• 정해진 건 없는 거 같음
• 어떻게 나누고, 어떻게 구성하고 어디에 로직 처리를 둘지 의존성을 고려하면서 설계하는게 아키텍처의 핵심인듯
• 일관적인 아키텍처를 고수하려고 노력해야 하는듯 ?

---

배운 점

• 소프트웨어 아키텍처 패턴 MVC, MVP, MVVM 각각의 특성을 알아봄
• Clean Architecture를 어떻게 구성해야 할 지 고민해봄 → VIPER 라는 아키텍처도 알게됨
• MVVM + Clean Architecture를 통해 실습 적용까지 해봄

---

참조 링크

MVVM과 Clean Architecture

MVVM과 Clean Architecture

[SUB] 도대체 어떻게 하는 것이 MVVM 인것이냐? 오늘 결론 내립니다.

[SUB] MVC, MVP, MVVM 차이점 알아보기

Clean Architecture 에 대해서 알아봅시다.

[SWIFT] MVVM 디자인 패턴

[SWIFT] MVVM 디자인 패턴