[질문] MVVM 패턴중에

[익명(221.145)]

ViewModel 이새끼 정확히 뭐하는 새끼임 쉽게 설명좀...

[라면의근본삼양라면(211.234)]

뷰에 대한 모델

[익명(221.145)]

자동차라 치면 엔진?

[라면의근본삼양라면(211.234)]

캘린더 앱을 제작한다고 가정해보자 현재는 선택 날짜를 빨간색으로 보여준다고 하면 선택 날짜에 대한 관리를 viewmodel에서 하고 주어진 날짜를 빨간색으로 보여주는 건 view에서 담당하면 되겠지?

[라면의근본삼양라면(211.234)]

사실 뇌피셜임 ㅅㄱ

[프로그래밍(nowadays3724)]

모델 혹은 모델에서 나온 데이터들 중에서 View로 보여줄 데이터를 ViewModel이라함. ViewModel을 수정하면 트리거가 발동되어 View까지 수정되어 보일수 있도록 매커니즘이 되어있다

[프로그래밍(nowadays3724)]

https://learn.microsoft.com/en-us/dotnet/architecture/maui/mvvm

[익명(doslim)]

뷰에서 보여주고 처리될 데이터가 뷰모델에 들어감. 어떤 리스트를 표현하고 싶다면 뷰에 Listbox가 있고 뷰모델에는 List<Data>가 있음. 뷰에서 뷰모델의 updatelist() 같은 함수를 실행하면 뷰모델에서는 로직을 수행하고 notify() 같은 함수를 호출함. 그럼 뷰에서는 바뀐 값을 자기 뷰에 맞게 적절히 바인딩 해서 보여주는거임.

[익명(doslim)]

그래서 데이터 흐름이 하나로 흐르게 해야함. 뷰에서는 뷰모델 함수를 호출하고, 뷰모델에서는 모델에 있는 것들을 호출. 뷰모델에서는 ui관련된 기능을 아예 모르는 채로 notify만 하는거임. 순수 mvvm으로 한다면 그 반대로 기능을 호출하는 경우는 없어야함.

[익명(39.120)]

모델과 뷰 사이의 연결지점

[익명(14.36)]

View를 추상화한 게층. 여기서 추상화한 계층이라는것은 정말 순수하게 기능역할만 하는것임. 버튼이라고하면 버튼 클릭 이벤트에 대한 내용과, 버튼에 들어갈 라벨등이 추상화되겠지. (사람들마다 추상화에 대한 정도는 다를 수 있음). 플랫폼 비종속적이며, MVVM은 처음에 MVC의 Controller-View 사이에 플랫폼 의존적으로 바인딩이 되어있는것을 방지하려고 만들었다고 들었음.

[익명(14.36)]

MVVM만 놓고보면 VM이 더 이해가 안되는데 MVC와 비교해서 보면 편함. MVC는 버튼을 그린다고하면 Controller가 View, Model을 활용해서 View의 내용을 채우는 관점임. 그래서 Controller가 과도하게 비대해짐. 코드의 관심사 분리가 안되는거임. 어떤 코드는 상태를 관리하고, 어떤 코드는 모델을 트리거하고, 어떤 코드는 이벤트를 관리하고.. 등등.. MVVM은 이런 Controller의 역할을 분리함. View는 순수하게 UI만 그리고, 이벤트 받아서 전달하고, ViewModel은 View의 추상화된 버전으로써, 그 받은 이벤트들이나 상태들을 관리하는 계층임.

[익명(14.36)]

이렇게 되면 MVC 희망편이라고할 수 있겠지만. 항상 아키텍쳐에서 두 계층을 분리한다는것은 나눠진 두 계층을 어떻게 바인딩할거냐의 책임을 누가 가져갈거냐가 남음. Controller가 암시적으로 해줬던 컨트롤링 역할을 ViewModel, View가 각각 나눠서 서로서로 싱크를 맞춰줘야함. (2-way-binding) 아마 MS쪽은 플랫폼 자체가 MVVM이 자동으로 바인딩되록 지원도는것으로 알고있고, 모바일쪽은 그런게 안되서 직접 Rx등을 활용해서 직접 구현하는것으로 알고있음.

[익명(14.36)]

여기서부터는 개인적인 생각이지만. 과연 MVVM을 구현한다고 해서라도 좋은걸까? 라는 생각이 있음. 위에서도 말했지만 ViewModel이라는게 사람들마다 추상화에 대한 레벨이 달라서 도대체 어디코드에 어떤게 들어가야하는지 애매해지는 문제가 있는듯? 
(MVVM관련 질문나오면 항상 이런 이야기 나오는듯. 뭐가 VM이고 이 코드는 VM에 들어가야하는지 M에 들어가야하는지..) 확실한 장점은 ViewModel코드는 플랫폼 비종속적이라 View가 모바일이든 웹이든 어떤 플랫폼이든 바인딩만 된다면 재사용할 수 있다는 장점은 있음. 근데 사실상 그런앱 안만드잖음.

[익명(14.36)]

MVVM의 지원이 빠방한 플랫폼이 아니라면 난 그래서 Flux를 선호함. VM, M 나누지않고 플랫하게 가면서 앱이 다음상태가 어떤상태인지만 정의하면 되는 구조라서 개발자가 인지하기 쉬움. Flux는 물론 선언적인 UI가 지원되어야 의미가 있는 형태지만, MVVM을 구현할 정도의 2-way-binding시스템을 가질 정도라면 이미 선언적 UI는 어떠한 방식으로도 구현할 수 있을거임.]

[폭진이(miraed)]

그냥 취향차이 아님 난 안쓰는게 더편한데

[냥(14.36)]

view model은 view에 들어갈 자료만 들어가야 함. model에 있는 자료 중 이 view에 출력할 자료만 있음. 현재 프랑스어 사용자라면 view에 영어, 프랑스어, 한국어 문자열이 있다면 프랑스어 문자열만 view model에 들어가야 함. 자료 변환 기능 같은 것은 없고 UI에 직접 출력, 입력 받을 자료 변수만 있음. check box라면 대응하는 boolean 변수가 있어야 함. 로직이 없는 순수한 자료이기 때문에 UI에 대한 간접적인 테스트가 가능함.

[익명(110.35)]

view 는 순수한 view 로직 view model 은 view 로 보여줄 무언가를 모델링 해놓은 거임. 그래서 view model 에 변화가 생기면 view 가 바뀌는 것 model 은 비지니스 객체 모델링