1. 기존의 문제점
- 트리 구조가 깊으면 깊을 수록 상태와 행위를 전달하는게 힘듦
생성자의 매개변수로 계속 전달해야 함
- 상태가 변경될 때 전체가 리로드 됨
필요한 부분만 다시 그려지면 됨
- 트리 구조를 잘 짜기 힘듦
최단 거리에 공통조상을 만들어야 함
그림만 그릴 때 → 컴포넌트로 잘 나와야 함
컴포넌트가 없으면 트리구조가 없는 것
데이터 관점 → 컴포넌트로 나눠야 데이터 관리가 됨
2. 단점을 해결하기 위한 라이브러리
- Provider(플러터 공식)
- RiverPod(공식을 만든 개발자가 개발)
- Bloc(다 씀)/Cubit
- Getx(중국에서 만듦)
- Redux
스프링에서는 MVC패턴을 프레임워크로 만들어서 사용해봤듯이 라이브러리 사용시에 구조(패턴)를 다뤄야 함
3. MVVM패턴
클라이언트앱에서만 사용 가능 / 프론트에서만 사용 가능!
- M : 모델(데이터를 담음) → DB에서 가져온 데이터를 저장하는 곳
- V : 뷰
- VM : 뷰 모델 → 화면을 위한 완벽한 데이터 = DTO와 비슷한 개념
- 사용 방법은 매우 자유로움
- 클라이언트가 뷰(그림)에 요청 → 모델(서버)에 요청해서 데이터를 모델에 담음 → 뷰모델에 전달해서 그림을 그림
EX) 뷰에서 데이터를 받아서 통신
→ 받은 데이터를 모델에 저장
→ 뷰 모델에서 데이터를 가지고와서 필요한 데이터만 뿌림
뷰 모델의 데이터가 바뀌면 자동으로 뷰에 적용이 됨
- 카메라를 사용할 경우 사진 데이터도 추가로 필요할 때가 있음
여러 데이터가 필요할 수가 있음!
4. MVC패턴 VS MVVM패턴
MVC패턴
- 뷰는 모델의 데이터를 합침 → restAPI의 DTO역할을 알아서 함
- 다되면 뷰를 응답
- 재요청시
서버가 클라이언트의 상태를 영원히 저장할 수 있다는 가정
- 모델 데이터가 응답하고도 살아있음 → 재요청시 모델 데이터 체크
추가 건수만 조회해서 추가하기
- 2번을 삭제했다면?
- 리턴으로 findByAll해서 뿌려주면 됨
- 부화가 커서 저장하지 않음
플러터의 경우
MVC 패턴
- 프러터가 restAPI서버측으로 요청을 함
- 서버가 DTO를 응답함
- 플러터도 레파지토리에서 받음
- 뷰가 레파지토리로부터 모델(데이터)을 받아 뿌리면 픽스됨 뿌리고 데이터가 날아감
데이터가 아니라 그림일 뿐
- 재요청시 1건이 추가되면 전체를 조회해서 다시 DTO로 받아서 뷰에 전체를 그려야 함
데이터가 없으니 이전의 데이터가 없고 비교할 수가 없어서 다시 그려야 함
MVVM 패턴
- VM으로 모델 데이터 관리하는 것이 효율적임!
- VM이 뷰의 상태값임!! 상태를 관리할 수 있음
- 뷰랑 레파지토리랑 연결을 안하고 VM과 연결
- 뷰가 VM에 요청해서 데이터가 있는 레파지토리에 요청
- 레파지토리가 서버에 요청해서 데이터(모델)를 받음
- VM이 데이터를 받아서 데이터를 기반으로 뷰를 다시 그림
- 재요청시 모델은 사라졌지만 VM의 데이터는 살아있음
- 삭제 요청시 VM이 가지고 있으니 삭제 요청후 VM이 가지고 있으니까 조회할 필요는 없음/ 플러터의 where로 날리기
- 클라이언트가 자기꺼 하나니까 부화가 크지 않음
- 삽입 요청시 DB에 데이터 추가해서 받음
- 모델로 1건 받음
- VM에 추가된 데이터를 추가만 하면 됨 정규 연산자로 가능
- 데이터 수정시도 마찬가지 상태를 가지고 있으니까 변경된 데이터만 반환해주면 됨!
- 모델의 정보를 가지고 화면에 그리는 것이 베스트이나 안될 경우가 있음
- 변수가 true/false일 때 화면에 true가 아니라 완료라고 가공해서 뿌려야할 경우가 있음 → vm에서 가공 가능!
앱에서 vm을 쓸 수도 있고 안 쓸 수도 있음
- 서버에서 전체를 다시 조회해서 좋음
- 삽입하니까 서버가 전체를 줘서 전체를 받음 → vm의 데이터를 갈아없으면 안쓰는 것!
- 전체 줄 필요없고 바뀐 데이터만 알려줘 하는 백엔드와의 커미션도 필요함!
- 바뀐 데이터 응답 받고 다시 findAll을 요청해서 다시 가져와서 덮어씌워야 함
→ 프론트와 서버 둘다 부화가 심해짐
Share article
