스위프트 스터디 (MVC to MVVM 개념정리 Swift UIkit Fundamental )

정성윤·2023년 5월 29일
1

Swift 이론

목록 보기
1/64
post-thumbnail

MVVM(Model, View, Viewmodel)
기존의 uikit는 mvc를 따르고 있다.MVC(Model View Controller)

Clean Architecture의 핵심은 바깥쪽 레이어가 안쪽 레이어에 대한 정보는 알아도 되지만, 안쪽 레이어는 바깥쪽 레이어에 대해 최대한 몰라야 한다는 것이다.

외부 사항은 서비스가 완성이 되어 배포한 후에도 교체 및 수정의 가능성이 있지만, 내부의 룰은 변화의 가능성이 적다. >> 외부사항들을 변경 시킬때 마다 내부 사항을 변경해야한다면 비효율적일 것이다.

Domain Layer = Entities + Use Cases + Repositories Interfaces
Data Repositories Layer = Repositories Implementations + API (Network) + Persistence DB
Presentation Layer (MVVM) = ViewModels + Views

프로젝트의 핵심 비즈니스와 관련 없는 외부 사항에 대한 결정을 최대한 미룰 수 있는 장점이 있다.

Clean - Architecture에서 다른 구조보다 MVVM이 많이 사용된다. ViewModel이 독립적으로 테스트 가능하고, ViewModel이 어떻게 그릴지에 대한 고려를 하지 않아도 되게 만들어서 한 층 위인 View에 대한 고려가 완전히 필요 없어졌기 때문이다.

원 안에 있는 요소들에 대한 설명.

Domain Layer
중심에 위치한 부분이 도메인 레이어. 어플리케이션의 주제 영역을 표현하는 엔티티, 데이터 이러한 것들을 조작하는 코드가 포함된다. 도메인은 다른 어플리케이션과 구분 가능하게 하는 핵심.
Entity
외부 변화가 있을 때 가능성이 가장 작은 요소.
데이터 구조 및 함수 집합, 변수들 담는 공간.

Ex) Codeable

Application Layer
도메인을 둘러싸는 것. 유저의 시나리오와 같이 Use Case를 묘사. 어떤 이벤트가 발생했을 때 무엇이 일어날지에 대해 담당한다.

"카트에 추가하기" 시나리오는 Use Case. 버튼이 클릭되었을 때 일어나야하는 액션에 대해 묘사.

1. 서버에 요청을 보내고
2. 도메인 변환을 수행하고
3. 응답 데이터를 가지고 UI를 다시 그립니다.

Use Cases
Clean - Architecture의 핵심. 모든 것은 Use Cases를 통해서 이루어진다.
Use Cases는 Entity와의 데이터 흐름을 조정하고, 해당 Entity가 Use Cases의 목표를 달성하도록 지시하는 역할을 한다. 사용자가 시스템(서비스)를 통해서 하고자 하는 것을 의미한다.

Entity를 활용하여 비즈니스 룰을 실행하는 단계.

좋은 아키텍처를 만들기 위해서는 Use Case가 안정적으로 잘 만들어져 있어야 하고, 그 외의 도구들은 언제든지 바뀔수 있으므로, 결합도를 최대한 낮추는 것이 중요하다.

Adapters Layer
가장 바깥의 레이어는 외부 서비스로의 어댑터들을 포함한다. 어댑터는 호환되지 않는 외부 서비스의 API들을 우리의 필요에 맞게 변환하기 위해 필요하다.

어댑터
1. driving(인바운드) - 우리 어플리케이션으로 신호를 보내는 종류
2. driven(아웃바운드) - 우리 어플리케이션으로부터 신호를 받는 종류

유저의 상호작용은 대부분 driving 어댑터들과 일어난다. UI프레임워크의 버튼 클릭 핸들링은 driving 어댑터의 일이다. 브라우저 API와 작동하며 이벤트를 우리의 프로젝트에서 이해할 수 있는 신호로 변환해 준다.

Driven 어댑터들은 인프라(infrastructure)와 상호작용한다.
Ex) 프론트엔드에서의 인프라는 백엔드 서버. >> 가끔 다른 서비스(검색엔진)들과 직접적으로 상호작용

중앙에서 멀어질수록 코드 기능은 더 "서비스 지향적"이며 응용 프로그램의 도메이니 지식과는 거리가 멀다.

나중에 우리가 어떤 모듈이 어느 계층에 속해야 하는지 결정할때 중요.

Dependency Rule
Layer Architecture는 의존성 규칙이 존재한다. 바깥쪽에서 안쪽으로만 의존성을 가질 수 있다.
1. 도메인은 반드시 독립적이여야 한다.
2. 어플리케이션 레이어는 도메인에 의존성을 가질 수 있다.
3. 바깥의 레이어는 어디에나 의존성을 가질 수 있다.

바깥쪽의 레이어만이 안쪽의 레이어에 의존성을 지난다.

but, 꼭 지킬 필요는 없음. 라이브러리같은 코드를 의존성이 존재하면 안되는 도메인에 두는 곳이 편리할 때도 있음.

의존성 역전 법칙 : Use Case에 Output Port라는 Interface를 둬서 Presenter처럼 바깥 원의 내용을 직접 참조하는 것이 아닌 Interface를 참조하면 된다.

Interface Adapters (Controllers, Gateway, Presenters)
Interface Adapters는 Presentation Layer라고도 불린다. 이 Layer에서는 데이터가 들어오면 Entity와 Use Cases에 가장 편리한 Format에서 외부 프레임에 가장 편리한 Format으로 변환된다.

Data Flow
Clean-Architecture와 MVVM을 합친 예시 앱의 코드를 보면서 흐름을 파악하면 좋다.

Example) 유튜버 - 개발하는 정대리 참고

화면에 리스트가 있다고 봤을때, 화면에 리스트에 대한 데이터는 뷰 컨트롤러가 전역 변수로 일반적으로 가지고 있다. 로직이 뷰 컨트롤러 안에 존재한다. 뷰 컨트롤러 = 뷰로 보고, 뷰 모델에서 데이터를 가지고 있다.
여기서 가지고 있던 데이터를 뷰 모델이 데이터 상태를 가지고 있고, 데이터가 변경이 되며 >> 서로 묶어주는 역할만 하게 된다.

다른 역할 수행 로직은 다른 곳에서 실행된다. 이렇게 되면 부담을 줄일 수 있게 된다.

Clean - Architecture의 필요성

구현하기

데이터를 발산하기 위해 ovservableObject로 선언. 데이터 상태를 가지고 있다.

여기서의 뷰모델은 - 뷰와 관련된 모델.

데이터를 감지하기 위해 사용되는 것이 보통 >> 데이터를 변경되는 애가 Published를 붙여야함.
퍼블리시를 이용하면 데이터가 변경되었다는 것을 감지 가능.


뷰 컨드롤러라는 것이 뷰 모델을 하나 가지고 있다. 바로 생성을 해주면, 뷰 컨트롤러가 생성될때 뷰모델이 함께 생성 된다.

extension fileprivate. sink 퍼블리셔에 가져오는 데이터를 받을 수 있게 해준다.
combine >> disposalbleBag : 버리는 데이터. Set .store(in: &disposalbleBag).

결론 >>
뷰와 모델은 서로 소통하지 않는다. 징검다리 역할을 하는 viewmodel을 통해 소통한다. 모델은 단순히 하나를 뜻하지 않는다. 데이터를 가공한 정도에 따라서 entity, model, viewmodel로 분류 가능하다.

모델은 그 자체로 하나가 아니다. 어댑터들 덕분에 외부 서비스들이 교체 가능해진다. 인터페이스가 바뀌지 않는 한 어떤 외부 서비스가 인터페이스를 구현하는지는 상관이 없어진다. 이러한 방법으로, 전파에 대한 방어막을 생성할 수 있다. 타인의 코드가 바뀌더라도 우리의 코드에서는 직접적으로 영향이 오지 않는다.

어댑터들을 또한 어플리케이션 런타임 중 버그의 전파도 제한한다.

Costs Of Clean Architecture
모든 도구와 같이 클린 아키텍쳐 또한 장점만이 아닌 비용도 존재한다.
Tasks Time: 가장 큰 비용은 시간이다. 설계 시에는 시스템이 어떻게 바뀔 수 있는지를 염두에 두고 확장의 여지를 남겨 둘 필요가 있다.

참고 사이트
https://velog.io/@bluejoyq/번역-Clean-Architecture-on-Frontend
https://velog.io/@sungmincho/Architecture-CleanArchitecture
https://velog.io/@wannabe_eung/iOS-MVVM-Clean-Architecture에-대한-고찰
https://www.youtube.com/watch?v=TLX7MjtOPd0

profile
이유있는 스위프트 개발자

1개의 댓글

comment-user-thumbnail
2023년 5월 30일

좋은 정보 감사합니다! 도움이 많이 되었어요 !!

답글 달기