.NET MAUI에서 기본 MVVM 아키텍처 설정 | Pieter Nijs

❎ Xamarin/MAUI 소모임
1

Pieter Nijs님이 .NET MAUI에서 사용할 수 있는 MVVM 아키텍처를 단개적으로 구현하면서 설명하고 있습니다. 현재 MAUI 미리보기 12에서는 Prism이나 FreshMVVM가 제대로 동작하지 않는다고 합니다. MAUI용 FreshMVVM은 이곳에서 확인하실 수 있습니다.

MAUI와 상관없이 이 글을 통해 일련의 MVVM 구조에 대해 이해하고 어떻게 동작하는지를 파악할 수 있으므로 MVVM 및 MVVM 아키텍쳐에 대해 궁금하신 분도 참고할 수 있는 유용한 자료입니다.

2개의 좋아요
2

MAUI 에서 사용하는 MVVM 패턴이

다 좋았는데 몇 가지…

MainPage 생성자에서 아래처럼

public MainPage(MainPageViewModel viewModel)
{
    BindingContext = viewModel;
    InitializeComponent();
}

ViewModel 의 타입을 지정하여 받도록 하는 건 조금 아쉽습니다.
Ioc 에서 DI 로 밀어줄 시그니처를 결정하기 위해 이렇게 만든 거 같은데
DI 를 사용할 목적으로 봤을 때는 문제가 없겠지만,
MVVM 관점에서 본다면 View 의 추상화를 약화시키는 요인이 될 수 있을 거 같네요.
(생성자의 인자에 ViewModel 타입이 명시되기 때문에 그 자체로 View 와 ViewModel 간 강한 타입 의존성이 발생합니다.)

굳이 Ioc 의 혜택을 받기 위해서였다면
MainPageViewModel 처럼 타입 명시보다는 인터페이스를 이용했으면 어땠을까… 하구요.

아예 Ioc 차원에서
View 와 ViewModel 할당하는 과정을 자동으로 처리해주는 기능이 들어가 있으면 베스트이지 않을까 싶어요.
(이런 측면에서는 Prism 이 대박인 거죠… =ㅂ=b)

또 뭐,
중간에 ViewModel 에서 직접 Page 객체에 접근하는 구간도 보이는 등등의 내용은 좀 아쉬운 부분이긴 합니다만

이런 글들을 보면서 새삼 아키텍처에 있어서 무엇이 중요한가… 를 다시 되새겨 보게 되네요.

결국 MVVM 이 추구하는 것 자체가 이해하기도 어렵고 구현하기도 어렵다보니
View의 추상화에 집중하는 패턴 구현보다는, 사용 편의를 위한 기능적 구현이 주를 이루는 게
그냥 요즘 추세인 것 같습니다.
(MVU MVI 등등이 나온 이유도 마찬가지일 테죠…)

역시 이해하기 쉽고 쓰기 편한게 짱이구나 하는 생각이 듭니닷 -ㅁ-b

3개의 좋아요
3

네. 사실 이상적인 디자인은 현실에서 되려 복잡하게 반영되는 경우 왕왕 있죠. 그렇다고 너무 실용주의로 가면 구조화 스킬이 안늘고… 이상적인 디자인을 어떻게 하면 실용적이게 가다듬느냐가 개인이나 팀이나 회사 관점에서 이로운 것 같습니다.

개인적으로는 View는 ViewModel을 알게 전개합니다. View가 바라보는 ViewModel까지 일반화 하기에는 이점보다 작업량이 급증하는 등 해가 많더라고요, 그런데 ViewModel이 View를 모르게는 디자인 합니다. 만약 View를 참조하는 순단 MVVM의 이점은 0에 수렴하는거라고 생각하거든요.

1개의 좋아요
4

넵. 그렇숩니다… =ㅂ=;

당연히
개념의 구현이 편의에 심각한 영향을 주면 안 되겠지만,
그 반대 역시 금과옥조로 다뤄질 필요는 없다고 생각해요.

그 가장 앞부분에 있는 것이
View 에서 ViewModel 을 타입으로 참조하는 것이라고 개인적으로 생각하는 편입니다.

하지만 만약 이렇게 ViewModel을 타입으로 View 에 참조를 하는 상황이라면
View 에서 ViewModel 에 대한 직접 접근은 허용하지 않아야 할 거 같다는 게 제 생각입니닷!
(하지만 그게 가능할까… 싶어요… =ㅅ=??)

그리고 특히! code behind 에서는 덕욱 그래서는 안 된다고 생각해요. 또한
Zero Code Behind 를 컨벤션으로 채택하지 않는 경우라면 더더욱 위험하다고 생각합니다.

협업하는 모든 구성원들이 MVVM 에 대한 이해가 깊다면 크게 상관없을 수도 있지만
(각자 알아서 조심할 테니까…)
만약 그렇지 않다면, 게다가 코드 리뷰도 제대로 안 된다면…
크흐… ;ㅂ;

그러니까
단순히 ViewModel 을 DataContext 에 할당하는 용도 이외에는 사용하지 않게 한다면 그나마 낫겠지만
애초에 View 에서 ViewModel 을 알게 했다는 것은 ViewModel 타입에 대한 참조가 가능한 상황을 만들어 둔 것이고,
이것은 View에서 ViewMode 에 직접 접근할 수 있는 통로가 열린다는 의미이죠.

그러다보면
ViewModel 에서 수행해야할 비즈니스 로직이
View 의 code behind 에서 ViewModel 에 접근해 쭉쭉 커가는 경험을 쉽게 할 수 있거든요.
(눈 앞의 구현에 바쁜 사람들이 MVVM 고려할 리가…)

그렇게 되면 결국
ViewModel 은 Data Binding 을 지원하는 수준의 유틸 타입으로만 사용되는 것으로 이어집니다…
(이럴 거면 굳이 MVVM 을 쓸 이유가… 어차피 짬뽕인데…)

이게 MVVM 의 이해도에 관련된 문제이긴 한데
모든 팀원에게 이것을 요구할 수 없는 상황이 더 많죠.

그래서, 저는 개인적으로
이런 상황에서도 최소한의 패턴 구현을 위해 일종의 장치를 마련해두는 편이에요.

예를 들어 Zero code behind 나 View 에서 직접 ViewModel 의 타입에 대한 접근을 제한한다거나(요거는 컨벤션으로 처리…)

아예 View 와 ViewModel 을 별도의 어셈블리에 작성하고 프로젝트 수준에서 참조하지 못하게 한다거나… 등등
(사실 이렇게 하면 View 가 ViewModel 에 직접 접근이 구조적으로 불가능해지죠. 깔끔… /ㅁ/)
뭐 그렇숩니다…

MVVM 을 메인 아키텍처로 선택했다면
그것을 구현하면서 어떤 이점을 취할 지 생각해야하고, 패턴을 깨면서 어떤 영향이 있을 지 고려해야하겠죠.

저는 웬만하면, 패턴을 깨면서 얻는 편의보다 패턴을 지키면서 얻는 이득이 훨씬 크다고 생각하는 편이라
이런 부분에 대해 좀 민감하게 받아들여지기도 한답니다…

그냥 그러려니 해야하는데 말이죠… -ㅁ-;;;

2개의 좋아요