[Flutter] Provider를 사용할 때, File Structure 제언

21. 11. 24.

- Could -

1. provider, getx, bloc
2. provider를 위한 File Structure

 

1. provider, getx, bloc

https://pub.dev/packages/provider

provider | Flutter Package

플러터를 학습하다보면 한번은 꼭 공부해야 하는 상태관리 패키지이다. Provider 말고도 Bloc이나 Getx같은 패키지도 있으니 알아보기 바란다. Bloc같은 경우는 패키지 보다 하나의 디자인 패턴에 가깝고, Getx는 상태관리 기능 말고도 상당히 많은 기능을 제공하고 있다.

위에 get이 Getx이고 아래 provider가 provider이다.

Likes 수를 보면 provider보다 getx가 더 많다. 많은 사람들이 getx를 좋아하지만, 요즘 보면 안티도 늘어나는 모양새(?) 인듯 하다. 한국의 플러터 커뮤니티에서는 getx의 편리함을 찬양하며 너도나도 쓰자고 하는 중인거 같지만, 외국에서는 안티들이 점점 많아지고 있다.

https://www.reddit.com/r/FlutterDev/comments/po1bei/why_is_getx_such_a_bad_state_management/

Why is getX such a bad state management?

고작 레딧 글 중에 하나일 뿐이지만, 이런 목소리는 계속해서 나오는 중.

 

개인적인 견해를 말하자면 Getx를 좋아하지 않는다. 편리한 것은 사실이지만, 하나의 패키지에 기능이 너무나도 많다. 하나의 패키지로 모든걸 해결할 수 있다는게 장점이라는 사람들도 있겠지만, 내 경우 각 패키지가 하나의 역할만을 제대로 하는 것을 선호한다. 해당 패키지에 문제가 생겼을때 여러가지 기능을 하나의 패키지에 의존적으로 사용하고 있다면 상당히 머리아픈 일이 될 것이다. 기본적으로 프로젝트 자체의 유연성이 떨어지게 되는 문제가 있다고 생각한다.

또 Getx의 반대파들은 프로젝트 규모가 커지는데 따라 발생하는 기능저하 문제와 아키텍처 결정의 어려움을 이야기하는데, 나름 읽어보면 고개가 끄덕여지는 내용이다. 찬성파들의 반대 주장도 끄덕여지긴 하지만, 반대판의 주장에 조금 더 마음이 간다. 무엇이 더 옳다는 것보다는 내 개인적인 선호가 getx보다는 provider와 bloc패턴에 있다는 정도로 받아들여주면 좋겠다.

 

다시 본론으로 돌아와서, google이 플러터에서 추천하는 디자인 패턴은 Bloc패턴이였으나, 2019년 Google IO에서 Provider가 추천되면서 주목을 받았다. 상태관리만 다루는 패키지이고, 이걸 패턴이라고 해야하나? 라는 의구심이 들 정도로 간단한 구조를 제시했기때문에, 중소형 규모의 프로젝트에 많이 추천되었다.

 

일단 provider의 장점은 구글에 검색해보면 많이 나오니 자세한 설명은 생략한다.

 

https://couldi.tistory.com/34

[Flutter] File Structure에 대한 제언

이건 앞서 추천 했던 file Structure에 대한 내용이다.

 

2. provider를 위한 File Structure

provider를 상태관리 패키지로 사용한다는 가정하에 위 구조를 조금 수정한 내용이다. 다시 한번 말하지만 공부하는 사람들을 위해 이런식으로 사용해보라는 추천이지, 절대적인 법칙이거나 한 것은 아니다. 개개인의 프로젝트 내용이나 팀 내의 컨센서스에 맞추어서 진행하면 된다. 기본적인 네이밍 컨벤션이나 다른 부분은 위의 글과 크게 다르지 않다. lib아래에 들어가는 폴더의 구조에서 조그마한 차이가 있을뿐이다.

• screens 폴더
  사람에 따라서 pages로 이름을 쓰는 사람도 있다. 화면의 UI들을 보관하는 폴더로, 특정 기능마다 화면 분류가 필요해 질 경우, 세부적으로 폴더들을 더 둘수 있다. 
• widgets 폴더
  이것도 UI를 담당하는 위젯들을 모아두는 폴더이다. screens 폴더와의 차이라고 한다면, screens폴더가 화면 전반을 담당한다면, widgets은 그 화면의 부분부분의 요소들 중 재사용되는 UI들을 모아둔 곳이라고 보면 된다.
• utilities 폴더
  앱에서 사용하는 function이나 logic을 모아두는 폴더이다. 
• providers 폴더
  provider와 관련된 클래스들을 정리하는 폴더이다. 일반적으로 provider의 전반적인 로직과 데이터 생성의 부분을 처리하는 부분을 따로 빼서 관리한다고 생각하면 된다. 
• models 폴더
  모델에 대해 설명하려면, 데이터베이스와 디자인 패턴에 대해 알아야한다. 이부분은 내용이 복잡해질수 있으므로 자세한 설명은 생략한다. 데이터베이스와 데이터를 주고받기 위해 사용하는 파일들을 모아두는 폴더라고만 생각하자.
• services 폴더
  이 폴더에는 앱 외부의 다른 서비스들과 앱을 연결할때 사용하는 내용들을 정리해준다. 위 제언글에서 providers 폴더가 담당하는 역할을 한다고 생각하면 된다. 

이 구조가 제일 깔끔한 것 같다. 모델 폴더에 묶어서 처리하기도 하는거 같던데.. 그냥 providers 폴더를 진짜 provider를 위한 폴더로 만들어 파일 구조에 논리적 일관성을 가져가는 편이 더 좋아보인다.

 

이것도 그냥 내 주장일 뿐이다. 정작 사용하는 사람들이 불편하다면, 사용하는 사람들의 편의에 맞추는게 맞다고 생각한다. 블로그에 검색해보면 다들 provider 패턴이라고 사용하는 방법에 대해서만 설명하길래, 이렇게 관리해보는게 어떨까라는 하나의 의견일 뿐이다.