[Flutter] Flutter bloc 클린 아키텍쳐 (1)

https://devmuaz.medium.com/flutter-clean-architecture-series-part-1-d2d4c2e75c47

Flutter Clean Architecture Series — Part 1

플러터 패턴을 너무 무작위로 하기보다 좋은 구조로 잡고 코딩을 하는게 좋을 거 같다 생각해서 좋은 글이 있는 것 같아 번역하면서 정리해보려 합니다.(영어 잼민이ㅜ)

 

 

기본적인 프로젝트 생성

counter_app
|-- android // 컴파일된 android앱
|-- ios // 컴파일된 ios앱
|-- lib // 99퍼의 시간을 할애하는 장소
	|-- main.dart // 프로젝트 진입점. 반드시 존재해야 하며 main() 메서드를 포함해야함
|-- test // 50퍼의 시간을 할애해야 하지만 (^^;;) 보통 0.1퍼센트의 시간을 사용
	|-- widget_test.dart 
.gitignore
pubspec.yaml // 모든 dart프로젝트에 필요하며 의존성과 메타데이터 관리
pubspec.lock // 편집하면 안되는 잠금(lock)파일 생성. pubspec.yaml을 업뎃할 때 이 잠금 파일을 갱신하며
// 호환되지 않는 패키지 버전을 사용하지 않도록 한다.
README.md

 

 

클린 아키텍쳐를 잡고 가면

장점

- 테스터블한 코드 및 확장성 있는 구조 

- 쉽게 유지 보수

- 프레임워크 / 툴의 독립성

- 큰 규모, 많은 개발자들이 들어간 큰 프로젝트에 적합(독립적인 형태로 구조화 되어 분업화에 용이함)

- 잘 구조화 됨

 

단점

- 보일러 플레이트 코드(획일성)

- 모든 프로젝트(회사 프로젝트의 방향성)에 적합하진 않을 수 있다 (각자의 스타일과 요구사항이 다를 수 있으니)

 

프로젝트

news 앱 ( REST API)을 데이터 요청해서 가져오고 디바이스에서 로컬로 데이터를 캐시하는 뉴스앱을 만듦.

이 앱에서 사용할 라이브러리, 폴더 구조 , 프로젝트 설정 및 주요 아키텍처 소개

 

기능

- 데일리 뉴스 List 가져오기

- 상세 기사 보기 

- 관심 기사 save 

 

 

사용할 패키지(라이브러리)

- retrofit

Dio(https://pub.dev/packages/dio) 를 http 클라이언트로 사용하는 소스코드 생성 패키지로 REST APIs 메소드를 적절하게 생성하도록 추상화 되어있다! (안드로이드 Retrofit에서 영강을 받음)

- floor 

  Sqlite를 사용하여 데이터를 로컬로 저장하는 typesafe하고 reactive한 경량 소스 코드 생성기 패키지. (안드로이드 Room에서 영감 받음)

 

- flutter_bloc

상태 관리 패키지 (react의 리덕스 같은) Provider같이 전역적으로 접근해야할 상태를 관리

 

- equtable

dart객체를 동등하게 비교하는 플러터 패키지?

 

- get_it

서비스 로케이터. DI 라이브러리로 (안드로이드 Dagger라는 DI 라이브러리에서 영감) 종속성을 수동으로 주입. 즉, 종속성 주입기..

 

- flutter_hooks

react hooks에서 영감을 받은 라이브러리로 상태의 불변성을 지키며 상태 변경

 

- lint

dart의 스타일 지침에 따라 깔끔한 코드로 작성하는데 도움을 주는 패키지

 

- ionicons

예쁜 아이콘 세트

 

 

REST API

https://newsapi.org/docs/get-started의 뉴스 API를 사용해 json으로 검색. 로그인해서 API키 얻어서 사용한다.

 

디렉토리 구조

lib/src 밑으로



 

DI (Dependency Injection)  하는 법
src내의 injector.dart파일은 get_it 패키지를 사용해 DI (종속성 주입)을 하는 역할을 함

 

아키텍쳐 설명

 

* config 

앱에 대한 구성이 포함되어 있습니다. (테마 , 경로 등등)

 

* core

앱 전역으로 필요한 핵심 학목이 포함되어 있음. 기능에 필요한 작업/ 액션 같은 것을 core에 구현

resources , utilities 등과 같은 폴더들도 포함할 수 있다.

 

 

 

 

data 계층 

맨 아래 레이어인 Data계층은 REST API, GraphQL 같은 http통신으로 받은 data , sqlite같은 local DB의 raw data를 <br>
  직접 처리하는 것. 그 다음 raw data(Json, Xml ..등)을 매핑하거나 직렬화하는 방법으로 Model(dart객체)로 변환해 매핑합니다. 
  
data계층의 models은 Domain계층의 entities와 다릅니다. 
이런 계층으로 나누는 이유는 raw data 직렬화를  Json에서 xml로 변견하려는 경우 이런 변경사항이 내부 entity (domain계층의 entity)에
영향을 끼치지 않기 때문.
Data계층의 Model은 Domain계층의 entities에서 property(속성)들을 확장하고 Model이 entities에서 모든 속성을 확장하므로 
항상 Domain계층에 종속됨.

domain계층에서 인터페이스(추상화된 클래스)를 정의.
data계층에서 repository를 포함하는 domain계층의 추상화 클래스의 실제 구현.
domain계층과 상호작용하지 않고 관심사를 분리해 여러 구현을 변경, 추가할 수 있어서 의존성을 낮출 수 있습니다.

presentation계층

이 계층은 2가지 중요한 부분이 있습니다. Bloc(ViewModel 포함)과 UI (widgets, state, animation..)

 * Bloc
 Bloc에서는 외부(remote또는 local)로부터 데이터를 필요로 하는 모든 상호작용을 이 bloc이 처리함 (redux같은..)
   bloc의 패턴은 단일 클래스를 갖는 대신 이러한 상호 작용을 Event로 분리하고 event를 처리하고 state의 결과를 UI로 리턴
   UI쪽에선 state의 상태를 (stream of states) 받아 action하고 위젯을 빌드해서 업데이트
   
bloc을 써서 event, state, bloc으로  role을 나누고 더 클린한 코드 베이스를 가져감.
presentation계층도 domain계층에 의존 - bloc이 주입(injected)된 domain종속성(ex. usecase)를 사용해서 작업 처리해서.

domain 계층 

- domain계층은 내의 entities만 포함하고, 우리 domain의 entities가 domain 계층 외부에서 발생할 변경 사항과
완전히 독립적임.
  
- persentation 계층과 data계층모두 domain계층에 의존함. (필수적인 의존성)
- data계층의 domain계층에서 작성된 계약(추상클래스)를 실제 구현 / presentation계층은 주입된 종속성으로 사용할 때 이런 계약들을 사용.

- presentation계층은 model이 아닌 entity로만 데이터를 얻어 각 계층을 독립적으로 분리해야함.
- 대형 프로젝트는 각 계층에 매핑 객체를 사용해 각 계층별로 상호작용하고 서로 종속되지 않도록 하는게 좋음 (해당 프로젝트는 작아서 그렇게까지은 안함!)

* usecase
usecase는 어떻게 사용되냐면 repository에 의존하는 개별 클래스로, 하나의 정확한 작업(기사 가져오기, data 게시, 로그인 등)만을 수행.
  usecase에 주입된 여러 repository를 취할 수 있고 bloc(viewmodel)은 그것에 주입된 여러 usecase를 사용할 수 있음.