[1] MVVM 데이터 바인딩이란?

 

https://youtu.be/fxlYxhhf83s?si=4AkXivZjY6zzQb_Y

 

MVC, MVP, MVVM 디자인 패턴과 관련된 영상입니다.

시간이 여유롭다면 시청을 추천드리며 굳이 영상 없이도 글로만 개념을 훑어보시는것도 좋습니다.

디자인 패턴이란?

다수의 개발자들이 시행착오를 거치면서 겪었던 부분들을 수정하고 개선하면서 만들어진 일종의 템플릿입니다. 굳이 말하자면 우리가 다룰것은 UI 구현하는 템플릿과도 같습니다.

왜 쓰는걸까?

여러분은 디자인패턴을 몰랐을 뉴비 때 아마도 그냥 모든 UI나 데이터가 변하는 코드를 한 스크립트에 꽉꽉 뭉쳐놨을겁니다. 그러면 나중에 문제가 생겼을 때 다시 그 문제 부분을 찾아보느라 시간을 버릴 가능성이 큽니다.

“ 각각의 역할을 나눠 코드 관리를 하자!“

이게 가장 중요한 이유입니다.

역할을 나누어 관리가 된다면, 유지보수와 개발효율이 좋아지겠죠?

이제부터 MVC, MVP, MVVM을 한번씩 훑어볼 예정인데 결국에 우리가 배우게될 MVVM에 다가가기전 다른 패턴들의 장단점을 보면서 MVVM이 꼭 정답이 아니란걸 알고 계시면 좋을 것 같습니다.

 

시작전 용어 정리

처음 접하시면 용어가 생소해서 이해가 안될겁니다. 한번 정리해드릴테니 아래에서 읽다 다시 돌아와서 보시면 될거같습니다.

질문은 언제나 환영!

Model - 데이터들을 모은 형상 그자체입니다. 그냥 데이터 구조체라고 보시면 됩니다.

View - 말 그대로 보여주는 화면 그자체입니다. UI의 각 요소들도 다 뷰가 됩니다.

ViewModel - 보여주기위한 데이터를 관리하는 친구입니다. 뷰의 데이터인것이죠.

Controller - 사용자의 입력을 받고 처리하는 친구입니다.

Presenter - 중개자, 사회자의 역할로 뷰와 모델의 중개자 역할을합니다.

MVC

Model - View - Controller로 구분되어있습니다.

위에 용어에서 적혀있듯이 컨트롤러가 사용자의 입력을 받습니다.

입력받은거에 맞게 컨트롤러가 데이터부분인 모델을 수정합니다. (데이터가 바뀜) 그리고 컨트롤러가 해당 모델에 맞는 뷰를 선택해준 뒤 모델을 호출해 뷰를 수정합니다.

컨트롤러는 여러 뷰를 선택할 수 있고 항상 꼭 컨트롤러로 모델을 호출해 뷰를 수정해야합니다.

하나의 컨트롤러가 뷰와 모델을 연결해주는게 가능한거죠.

느낌이 오셨겠지만 컨트롤러는 꼭 모델과 뷰를 연결해야하기에 프로젝트가 커지고 뷰가 많아지면(버튼 같은거) 조장역할을 맡은 컨트롤러가 엄청 커지고 복잡해지겠죠?

컨트롤러의 역할을 분배해주는 방법을 찾아봅시다!

MVP

Model - View - Presenter로 구분되어있습니다.

이전의 MVC에 비교해서 설명하겠습니다.

Model과 View는 MVC에서와 똑같고 Controller 대신 Presenter이 들어갔습니다.

Presenter이란 중개자, 사회자란 뜻으로 사용자가 뷰(버튼같은거) 눌러서 입력을 했으면 뷰가 반응을 하여 중개자에게 요청을 날립니다.

중개자는 이에 맞게 모델을 찾아 요청을 합니다.

모델은 요청을 듣고 수정할 부분을 수정한 뒤 다시 중개자한테 제출합니다.

중개자는 이를 바탕으로 뷰에게 바뀐 부분을 알려줍니다.

이에 맞게 뷰가 스스로 바뀐 데이터에 맞게 변하게 되는것입니다.

MVC와 반대로 꼭 컨트롤러를 안거쳐도 되니 뷰와 모델이 관계가 느슨해졌습니다.

다만 뷰는 중개자에게 의존적이기 때문에 한 뷰마다 한 중개자가 필요합니다.

너무 중개자에게 의존하기 때문에 좋지 않습니다.

그럼 이를 개선한 방법도 있지않을까요? 그게 바로 MVVM입니다.

MVVM

Model - View - ViewModel 로 구분되어있습니다.

지금까지 Controller 컨트롤러나 Presenter 중개자가 있었는데

이번엔 달랑 모델과 뷰만 있습니다.

그런데 자세히 보니 뷰와 모델이 합쳐진 뷰모델도 있습니다.

모델은 그냥 데이터들의 모음이고 뷰모델은 이를 연산하여 모델을 갱신합니다.

뷰가 해당 뷰모델을 참조해서 실시간으로 바뀐걸 보여줍니다.

어떻게 보면 중개자와 비슷한 역할의 뷰모델인데 차이점으론 뷰모델은 뷰가 누가 있는지 모른다는겁니다. 그럼 이제 서로 의존성이 다 느슨해졌고 간단해졌죠?

이렇게 완벽해보이는 MVVM이지만 구현방식이 다르고 생각보다 구현시 손이 많이 갑니다.

그래도 우린 유니티 개발자니 어떻게 유니티에서 MVVM을 구현하는지 다뤄보겠습니다.

데이터 바인딩이란?

MVVM에서 뷰가 어떻게 뷰모델을 참조할까요?

다른 웹앱들은 [뷰 클래스]에서 뷰모델을 소유하는식으로 되어있습니다.

근데 우린 유니티로 개발하니 에디터에서 지정해서 뷰가 뷰모델을 바인딩(Binding)하는 방식을 쓸겁니다.

데이터 바인딩이란 UI 요소와 데이터 소스를 연결하여 데이터가 변경될 때 UI가 자동으로 업데이트되도록 하는 과정입니다.

우리가 배운 MVVM에선 ViewModel의 데이터를 View에 자동으로 반영하는 기법입니다. Unity에서는 INotifyPropertyChanged 인터페이스를 사용하여 이 기능을 구현할 수 있습니다.

예를 들어, ListView(UI)와 ListViewModel(데이터 컬렉션)을 바인딩하면 List의 데이터를 변경 시 바뀐 뷰모델을 바인딩한 UI가 자동으로 갱신됩니다.

헷갈리겠지만 바인딩은 다른 뜻도 존재하므로 알아두시기 바랍니다.

• 변수 바인딩: 프로그래밍에서 변수를 선언하고 초기화하거나, 변수를 특정 값이나 객체에 연결하는 과정. ← 우리가 알고 있는 값 할당 느낌 int a = 10; 이런식
• 이벤트 바인딩: 특정 이벤트가 발생할 때 실행될 함수를 지정하는 과정. 예를 들어, 버튼 클릭 이벤트와 클릭 핸들러를 연결하는 것.

💡핵심 정리

지금까지 MVC, MVP, MVVM 디자인 패턴을 알아보면서 각각의 특징과 장단점을 알아보았습니다.

우리가 앞으로 쓰게될 MVVM 디자인 패턴의 배경을 잘 알게되셨을거라고 생각합니다.

또한 MVVM을 유니티에서 구현시에 쓰게될 데이터 바인딩 방식을 다뤘습니다.

다음 회차부터 본격적으로 MVVM을 유니티에 구현해볼 예정입니다!

수고하셨습니다.