1 of 54

MV(P)VM

MVVM에 P를 유동적으로 사용해보자

2 of 54

발표자 소개

Flutter Developer

GDG Songdo Organizer

Flutter Incheon Organizer

​

2022년 부터 Flutter 개발자로 개발을 하며 현재 Nsus Lab Korea 라는 곳에서 세계 1위 오프라인 포커 대회 (WSOP: World Series Of Poker)에서 사용되는 Flutter App을 개발 중

​

현재 Bahamas에 앱을 선보이며 올해 Vegas를 향해 달려 가는 중

3 of 54

Agenda

What’s MV~

1

MVVM/MVP

MV(P)VM

Props & Cons

Conclusion

5

3

2

4

Q&A

6

4 of 54

5 of 54

Whats MV~

아키텍처는 아주 오래 전 부터 논의 되어 왔던 이야기

1970년대 SmallTalk의 �MVC (Model - View - Controller) 를 시작으로

MVP (Model - View - Presenter)

MVVM (Model - View -ViewModel)

MVI (Model - View - Intent)

​

등등 끊임 없이 이야기되고 이를 여러 프로젝트에 알맞게 사용을 하고 있다.

6 of 54

MVVM

  • MVVM은 UI와 비즈니스 모델을 분리해서 유지보수를 쉽게 만든 구조.
  • View는 UI를, ViewModel은 UI 로직과 상태를 관리, Model은 데이터를 주고 받는 구조
  • 중요한것은 ViewModel과 View는 서로 바인딩되어있고 (Observer) View또한 Model을 직접 참조 하지않아서 느슨한 결합을 유지할 수 있는데 대표적으로 Jetpack Compose, 또 플러터에서도 해당 방법으로 사용됨

7 of 54

MVP

MVP의 경우 View와 비즈니스 로직을 Presenter가 담당하는 아키텍처

​

  • View는 UI의 요소를 표시하고 사용자 입력을 받음.
  • Presenter는 View와 Model간의 데이터를 처리하여 UI를 업데이트.
  • 해당 방식은 View가 Presenter에 의존적이기때문에 MVVM보단 결합도가 높지만 단순한 UI로직을 수행하기에 용이함.

8 of 54

그렇다면 둘의 장점을 같이 써보는건 어떨까?

9 of 54

MV(P)VM

View

Model

Flow (ViewModel)

​

​

​

​

UiAction

DataBinding

기존의 MVVM 구조에서 UiAction 이라는 View를 컨트롤 하는 것을 선택적으로 받아서 필요에 따라 활용 하는 것이 목적

10 of 54

MV(P)VM

View

Model

Flow (ViewModel)

​

​

​

​

UiAction

DataBinding

UiAction이 View에 있거나 없다면?�-> MVVM�UiAction이 ViewModel에 있다면?�-> MVP�

UiAction

11 of 54

12 of 54

13 of 54

사용된 라이브러리

14 of 54

파일 구조

≈

참고 : Flutter 공식문서 Architecture 부분

15 of 54

파일 구조

참고 : Flutter 공식문서 Architecture 부분

≈

16 of 54

구동 영상

17 of 54

View - ViewModel

18 of 54

View - ViewModel

19 of 54

MVVM

20 of 54

View(UiAction) - ViewModel

View

Model

Flow (ViewModel)

​

​

​

​

UiAction

DataBinding

21 of 54

View(UiAction) - ViewModel

22 of 54

View

23 of 54

View

24 of 54

View

25 of 54

ViewModel

26 of 54

View - ViewModel

27 of 54

View - ViewModel

28 of 54

MV(P)VM

29 of 54

View(UiAction) - ViewModel

View - ViewModel(UiAction)

View

Model

Flow (ViewModel)

​

​

​

​

UiAction

DataBinding

UiAction

30 of 54

View - ViewModel

31 of 54

View

​

32 of 54

View

33 of 54

View -

ViewModel

?

34 of 54

View -

ViewModel

35 of 54

View -

ViewModel

36 of 54

ViewModel

37 of 54

ViewModel

38 of 54

ViewModel

39 of 54

ViewModel

40 of 54

41 of 54

42 of 54

만약 UiAction이 없다면?

​

43 of 54

만약 UiAction이 없다면?

​

44 of 54

그냥.. BuildContext를 넘기면 안되나요?

45 of 54

no no no no no no no no

46 of 54

BuildContext는 반드시 View에서만…

  • BuildContext는 위젯의 구조, 리빌드를 하는 역할
    • 상태관리와 Lifecycle및 상태관리에 문제가 생길 수 있음.
  • Family에 BuildContext를 넣게되면 리버팟의 캐싱동작 방식에 문제가 생길 수 있음.
  • 비동기 작업 시 예측 불가능한 에러가 발생 될 수 있음.
  • 그리고…. 그럴꺼면… Getx를 쓰는게…

47 of 54

음…. 굳이 이렇게 써야 하나요?

48 of 54

49 of 54

Props

  • 화면의 상태가 다양해지는경우, 복잡도가 올라가는 경우에는 뷰가 더러워 지는 걸 방지할 수 있다.
    • 코드를 잘 분리하면되지않을까? -> 맞습니다.
    • 구조를 잘못짜서 한 화면에 상태가 너무 많은 것 아닌가? -> 맞을 $sudo..… 아닐 $sudo…
  • 이때 Flow의 로직만 바라보면서 해당 화면의 어떤 로직에서 어떻게 화면이 바뀌는지 한눈에 보기 편해진다.
  • 화면에 상태를 매번 만들필요도 없어진다.
  • BuildContext를 넘기는게 아니기에 안전하고 MVP이지만 Mixin을 통해 인터페이스로 의존을 하기 때문에 테스트 코드를 짤 수 있다.

50 of 54

Cons

  • Mixin을 통해 인터페이스로 action들을 override를 할때 context에 접근을 하려면 StatefulWidget으로 구현이 되어야 한다.
  • ViewModel의 장점 중 재사용이 불가능해 진다.(View - Viewmodel이 1:1 구조)
  • 작성해야할 코드가 많아진다. (UiAction Mixin)

51 of 54

그럼에도 쓰는 이유

  • 모든 것은 트레이드오프가 있는 법.
    • 화면의 복잡도가 올라갈 수록 이러한 구조가 보기 편한 경우가 많다.
    • 코드의 작성이 많아지지만 AI의 도움으로 해당 방법이 해결된다.
  • 유연하게 uiaction을 사용할수도, 안할 수 도 있다. 한 앱에 꼭 하나의 패턴만 있을 필요는 없다.
    • 처음엔 많이 낮설었지만 적응이 되다보니 유연하게 짜는 법을, 꼭 모든 코드에 정답은 없다고 생각을 하고 끊임 없이 생각을 하게 됨.

52 of 54

53 of 54

“If you want everything to be familiar, you will never learn anything new, because it can't be significantly different from what you already know.”

​

​

Simple Made Easy by Rich Hickey

54 of 54

Q&A

“

”