어쩌다보니 iOS 개발자

Clean Swift 아키텍처 기초 이론 본문

iOS 개발/아키텍처

Clean Swift 아키텍처 기초 이론

엔디엘(no Dream no Life) 2022. 4. 5. 08:27

이번 프로젝트를 진행하면서 클린스위프트 아키텍처를 적용해보고자 합니다.

목표는

1. Rx없이 순수 클린 스위프트 아키텍처를 적용해보기 (추후에 적절히 어디에 사용하면 좋을지 생각해보기 위해)

2. 단위 테스트 적용해보기(TDD 라기 보단 완료 후 단위 테스트를 작성하는 순으로 개발)

 

 

클린스위프트는 템플릿을 제공합니다.

물론 그냥 Xcode 에서 제공하는건 아니고.. 템플릿 다운로드 받고 설치까지 한 후에 가능합니다!

 

예를 들어 ListTodo 화면을 만든다고 가정하면

이렇게 각 컴포넌트를 한번에 생성해줍니다.

 

 

그럼 이제 각 컴포넌트가 어떤 역할을 하는지는 최소한 알아하니.. 

 

가장 중요한 핵심 컴포넌트는!  VIP(View Controller, Interator, Presenter) 입니다.

VIP Diagram

 

View Controller

- data를 화면에 뿌려주기

- 사용자와 인터렉션

 

Interactor

- View Controller에서 통신오면 어떤 비즈니즈 로직을 수행해야 하는지 제어(Worker에 일을 시킨다) 또는 직접 비즈니즈 로직을 수행한다.

- 필요한 데이터에 대한 유효성 검사 

- Worker에게 필요한 데이터를 전달하고 전달 받아서 Presenter에게 전송한다.

Presenter

- Interactor 에서 받은 데이터를 ViewModel로 포맷하고 이를 View Controller로 전달

- 데이터가 사용자에게 표시되는 방법을 결정

 

 

VIP 주기

1. IBAction 또는 ViewDidLoad() 등 Use Case를 트리거 한다. (무슨 말이지.. 모르겠지만.. 유저 액션이나 뷰 처음 들어왔을 때 처리해야할 API 등 로직을 실행한다 라는 말인듯..)

2. View Controller 는 Interactor 를 호출하여 비즈니즈 로직을 수행한다.

3. 비즈니즈 로직을 마치면 Presenter를 호출하고, 결과를 Primitive Types(???이게 뭔지 모르겠네요..아직 진행하지 않아서)로 형식화 시킨다. 

4. Presenter는 View Controller를 호출하고, 결과를 화면에 보여준다.

 

 



 

나머지 것들 (Models, Router, Worker)

Models

모델은 컨트롤러와 관련된 모든!!!!! 모델을 저장한다.

구조체 유형이며 request, response, viewModel 구조체를 포함한다.

import UIKit

struct TestModel {
    struct Fetch {
        struct Request
        {
            var itemId = 0
            var keyword: String?
            var count: String?
        }
        struct Response
        {
            var testObj: Test?
            var isError: Bool
            var message: String?
        }
        struct ViewModel 
        {
            var name: String?
            var date: String?
            var desc: String?
            var isError: Bool
            var message: String?
        }
     }
 }

펌) https://velog.io/@ssionii/Clean-Swift-a.k.a-VIP-%EC%97%90-%EB%8C%80%ED%95%B4-%EC%95%84%EB%9D%BC%EB%B3%B4%EC%9E%90

 

- Request: API request로 보낼 파라미터들

- Response: API response를 저장

- ViewModel: UI를 보여주는데 필요한 모든 데이터들

 

의문: ViewModel이야 그 컨트롤러나 뷰에 해당하는 것이기 떄문에... 문제는 안되지만

Request와 Response는 API 관련이라고 하는데 ..API 가 한 컨트롤러에 여러 개가 존재할 수 있고.. 그럼 여러 모델이 존재할 것이고

여러 컨트롤러에서 똑같은 API를 호출 해야할 수 도 있는데 Worker마다 똑같은 API를 만들어야 하는것인가??

공통으로 사용하는건 어떻게 처리해야 하며 공통으로 사용하는 모델은 어떻게 잡아야하는게 좋을까?

Worker는 API를 호출해 줄 뿐 직접적인 ??작업이 없는건가.. 그건 아닌데 

공통으로 API호출 부분을 만들어야 한다면 Worker의 존재 의미가 없지 않을까?? 

아키텍처는 정해진 부분은 없으니.. 

여기서 의문이 드는 핵심은 공통으로 사용하는 모델과 API 는 어떻게 구성할 것 인지?

 

Router

View Controller 간의 전환과 데이터 전달을 처리한다.

 

Worker

API/CoreData request와 response를 관리하며, interactor와 통신한다

 

 

이론은 이정도로 하고 

https://github.com/Clean-Swift/CleanStore

클린 스위프트를 적용한 심플한 프로젝트를 리뷰하면서.. 공부를 해보기로.. 

 

 

참고

1. https://velog.io/@ssionii/Clean-Swift-a.k.a-VIP-%EC%97%90-%EB%8C%80%ED%95%B4-%EC%95%84%EB%9D%BC%EB%B3%B4%EC%9E%90

2. https://eunjin3786.tistory.com/165

3. https://eunjin3786.tistory.com/383

Comments