1.
플러터를 공부중이라서 flutter를 키워드로 채용 공고를 조금 찾아봤다.
그 중에 "MVVM에 대한 높은 이해" 라는 구문을 발견했다. 뭔가 중요한 것들이니 채용 공고에서 명시해서 요구했겠지. 그런데 이 세 단어 모두 오늘 처음 보았다. 그래서 알아보기로 했다. 앞으로 공부하면서 더 잘 알게 될테니, 얕은 예습 정도를 해 보겠다.
MVVM(Model-view-ViewModel)
플러터에서만 사용되는게 아니고, 그냥 아키텍처 패턴의 한 종류인가보다. MVVM은 애플리케이션의 코드 구조를 체계적으로 정리하기 위해 사용된다. 사용자 인터페이스(UI) 코드와 비즈니스 로직을 분리하는데 도움이 된다고 한다. 높은 코드의 재사용성, 유지보수성, 테스트 용이성!
이름에서부터 알 수 있듯 세 개의 요소로 이뤄진다. Model, View, ViewModel 이렇게.
1. Model
- 앱의 데이터와 비즈니스 로직을 담당한다.
- 데이터베이스나 네트워크 호출, 로컬 상태 관리 등을 포함하며, 데이터의 정의 및 그에 대한 작업들이 여기 포함된다.
2. View:
- 사용자 인터페이스(UI)를 담당하는 부분이다.
- Flutter에서는 Widget이 View 역할을 한다고 한다.
- 데이터는 ViewModel로부터 가져오고, 로직은 포함되지 않는다.
- 뷰는 최대한 멍청하게, 뭐 가진 것 없이 만드는게 좋은가보다. 비즈니스 로직이 포함되지 않을테니까 말이다.
3. ViewModel:
- View와 Model 사이의 다리 역할을 한다.
- ViewModel은 데이터를 준비하고, View가 화면에 그릴 수 있도록 적절히 변환해서 제공한다.
- 사용자의 액션에 다라 비즈니스 로직을 처리하여 Model을 업데이트 한다.
- Flutter에서는 주로 상태 관리 라이브러리 (eg. Provider, Riverpod, GetX, ChangeNotifier 등등)를 이용해 ViewModel의 역할을 구현한다.
- 뷰 모델은 두 개의 책임을 가진다: 첫재로, 유저의 입력에 반응하고 (예를 들어 모델을 바꾼다던지, 네트워크 요청을 시작한다던지) 둘째로는 뷰가 내보일 결과 데이터를 제공하는 것이다.
모델과 뷰 사이에 '뷰모델'이 위치한다. 뷰모델은 다리 같은 역할을 한다. 뷰는 뷰모델의 존재를 알고 있지만 모델에 대해서는 모르고, 모델도 같은 식으로 뷰모델의 존재를 알고 있지만, 뷰에 대해서는 모른다고 한다.
항상 장점만 있지는 않을 것이다. MVVM 모델의 단점은 다음과 같다.
- 가파른 러닝 커브를 지닌 소프트웨어 아키텍쳐 패턴이다. 모든 레이어들이 어떻게 서로 작동하는지 이해하는데 조금 시간이 걸릴 수 있다.
- 많은 클래스를 추가하게 돼서, 낮은 복잡도의 프로젝트에는 적절하지 않을 수 있다.
참조(https://pieces.app/blog/using-mvvm-architecture-in-flutter)
2.
SingleScrollView로 칼럼을 감쌌다. 그랬더니 화면이 안보이는 것이다. 이전에는 Column 안에 이미지 두 개를 각각 Expanded로 감싸서 넣어 주었었다. 알아보니 SingleScrollView랑 Expanded는 같이 못 쓰는 것이었다. Expanded를 지워주고, 그냥 컨테이너 안에 든 이미지로 배치해 두니, 원하는대로 잘 화면이 만들어졌다.
3.
스크롤을 해도 계속 상단에 고정되면 좋을 친구들은 'AppBar'에 넣어주는 것이구나.
앱 화면 내용들을 컴포넌트화 해서, 분리 해 가면서 분석하고, 만드는 것이구나.
컴포넌트화란? 화면을 구성하는 블록을 여러 블록으로 쪼개서 컴포넌트로 만드는 작업. 플러터에서는 각 요소를 위젝으로 만드는 작업.