Flutter MVVM

Flutter의 아키텍쳐 패턴 중 하나인 MVVM에 대해서 학습해보도록 하자.

경력이 조금씩 쌓이니까 아키텍쳐 패턴 ,디자인 패턴의 중요도가 점점 높아지는 것 같다.

사실 알고 쓰기보다는 쓰다보고 나중에 보면 '이게 이런거지 않을까?~' 하는게 좀 더 많은 것 같다.

디자인 패턴의 경우 내가 느끼기엔 서로 비슷하고 모호한것도 있고 이걸 어떻게 적용할까? 가 조금 어려운 부분이였던것 같다.

아키텍쳐 패턴중 하나인 MVVM은

Model
View
View Model

로 나뉘어져 있다.

Model은 말 그대로 데이터를 표현하기 위한 모델이다. 사실 이 부분을 설명한다는게 뭐 ... DTO? VO같은 느낌?

View도 사실 뭐 말 그대로 뷰이다.. 보여주는 화면단?

View Model 이라는 개념이 조금 생소했다.

view와 model을 합친 개념이라는 뜻인걸까??

mvvm은 아래와 같이 표현하기도 하는것 같다.

Data Domain Presentation

Data DB,Json Data 등 다양한 데이터 소스 Api 호출 부분에 속한다. 추상클래스를 직접 구현하는 부분

class TestRepositoryImpl extends TestRepository {
	Future<void> getUser() asnyc {
		await http.get(Uri.parse()...
    }
    Future<void> insertUser() asnyc{
		await http.post(Uri.parse()... 
    }
    Future<void> updateUser(); 
    ...
}

Domain Business Logic 라고는 하지만 약간 interface 정의서 같은 느낌으로 이해했다. flutter의 경우 추상클래스에 속함

abstract class TestRepository {
	Future<void> getUser();
    Future<void> insertUser();
    Future<void> updateUser(); 
    ...
}

Presentation UI부분 Domain에 의존하여 작업을 하게 된다.

데이터의 종속성은 아래와 같다.
Presentation -> Domain <- Data

MVVM으로 아키텍쳐를 설계하게 된다면
다음과 같은 장점이 있다 ( 모두가 써놓는 흔한거 말고 내가 느낀점 )
1. 테스트 코드 작성에 용이하다. ( UI를 그리지 않고도 테스트를 작성할 수 있다. 데이터가 정말 명확하게 요청되고 api설계서대로 잘 들어오는지 타입은 맞는지 휴먼 에러가 있지는 않는지...)
2. interface만 보고도 어떤 역할을 할 수 있는지 알 수 있다. (이름만 명확한 클린코드 형태로 작성하였다면..? 사실 이런 부분에 대한 한계점도 존재한다)

내가 생각하는 단점으로는 아래와 같다.
1. 혼자 개발하는 경우 interface 가 필요 없을 수도 있다.
2. 개발의 완성도 ,유지보수 측면 보다는 무조건적인 속도가 중요한 프로젝트라면 mvvm은 불필요한 시간낭비 일수도 있다.(si의 경우 그럴거 같다.)

요즘에는 면접을 보면 아키텍쳐 패턴을 물어보고는 하더라.

사실 이 패턴이라는게 정답이 있는게 아니다보니까 어쩌면 귀에걸면 귀걸이 코에걸면 코걸이 같은 느낌이 강했다.

저 data,domain,presentation 의 큰 틀에 속하는 항목들만 잘 폴더에 넣어놓는다면 그것도 mvvm이 되는걸까?

정답이 있는게 아니다 보니까 신뢰성있는 개발자 (팀장) 이 정해놓으면 그것을 따라서 하던지 아니면 내가 팀장을 설득해서 바꾸던지.. 가 될 거 같다.