4.6 MVVM개요(Model/View/ViewModel) 및 MVVM Example
n Model-View-ViewModel(MVVM)
Model : 비즈니스 로직과 데이터를 캡슐화 한것이다. 앱의 데이터를 캡슐화 하는 비 시각적 클래스 이다. 따라서 모델은 비즈니스 및 유효성 확인 로직과 함께 데이터 모델을 포함하는 앱의 도메인 모델을 나타내는 것으로, 모델 개체의 예로는 데이터 전송 개체 (DTO), 일반 올드 CLR 개체 (POCO) 및 생성 된 엔터티 및 프록시 개체가 있다.
모델 클래스는 일반적으로 데이터 액세스 및 캐싱을 캡슐화하는 서비스 또는 리포지토리와 함께 사용된다.
View : 사용자가 화면에서 보는 구조, 레이아웃 및 모양을 정의하는 역할을 한다. 각각의 뷰는 비즈니스 로직을 포함하지 않는 제한된 코드 숨김으로 XAML에 정의되는 것이 이상적이며, 경우에 따라 코드 숨김 파일에는 애니메이션과 같이XAML에서 표현하기 어려운 시각적 동작을 구현하는 UI 코드가 포함될 수 있다. Xamarin.Forms 응용 프로그램에서 뷰는일반적으로 Page 또는 ContentView 자식클래스로 뷰는 객체가 표시 될 때 이를 시각적으로 나타내는 데 사용할 UI 요소를 지정하는 데이터 템플릿으로 표현할 수도 있다. 뷰로 사용되는 데이터 템플릿에는 코드 숨김이 없으며 특정 뷰 모델 유형에 바인딩 되도록 설계되었다.
코드 숨김에서 활성화 및 비활성화하지 않고 뷰 모델 속성에 바인딩하여 UI 요소를 사용하거나 사용하지 않도록 설정하는 것이 바람직하다.
뷰의 상호 작용 (예 : 버튼 클릭 또는 항목 선택)에 대한 응답으로 뷰 모델에서 코드를 실행하기위한 몇 가지 옵션이 있다. 컨트롤이 명령(Command)을 지원하면 컨트롤의 Command 속성을 뷰 모델의 ICommand 속성에 데이터 바인딩 할 수있다. 컨트롤의 명령이 호출되면 뷰 모델의 코드가 실행되는 것이다. 명령 외에도 동작을 뷰의 개체에 연결할 수 있으며 호출 할 명령이나 발생시킬 이벤트를 수신 할 수 있다. 이에 대한 응답으로 동작은 뷰 모델에서 ICommand를 호출하거나 뷰 모델에서 메서드를 호출 할 수 있다.
ViewModel : View를 나타내주기 위한 Model이며 프리젠테이션 로직과 뷰를 위한 데이터를 캡슐화하고 있다. 뷰 모델은 뷰가 데이터를 바인딩 할 수있는 속성 및 명령을 구현하고 변경 알림 이벤트를 통해 변경 사항을 뷰에 알린다.
뷰 모델에서 제공하는 속성 및 명령은 UI에서 제공하는 기능을 정의하지만 뷰는 해당 기능을 표시하는 방법을 결정한다.뷰와 뷰가 요구하는 모델 클래스들 간의 상호작용을 조직할 책임이 있으며 뷰가 표시하는 데이터와 Command를 구현한것이다. View보다는 Model과 유사하게 디자인 되며, View의 바인딩 될 때 가장 강력하다.
뷰 모델에서는 I / O 작업에 비동기 메서드를 사용하고 속성 변경사항을 뷰에 비동기 적으로 알리려면 이벤트를 발생시킨다. 뷰 모델은 뷰의 상호 작용에 필요한 모든 모델 클래스와 조화시키는 역할을 하며 일반적으로 뷰 모델과 모델 클래스 사이에는 일대 다 관계이다. 뷰 모델은 뷰의 컨트롤이 뷰에 직접 바인딩 할 수 있도록 모델 클래스를 뷰에 직접 표시하도록 선택할 수 있으며 이 경우 모델 클래스는 데이터 바인딩을 지원하고 알림 이벤트를 변경하도록 설계되어야 한다.
각 뷰 모델(ViewModel)은 뷰에서 쉽게 사용할 수 있는 양식으로 모델의 데이터를 제공하며 이를 수행하기 위해 때때로 데이터 변환을 수행하는데 이 데이터 변환을 뷰 모델에 배치하는 것은 뷰가 바인딩 할 수있는 속성을 제공하기 때문에 좋은 방법이다. 예를 들어 뷰 모델은 두 속성의 값을 결합하여 뷰로 표시하기 쉽게 만들 수 있다.
데이터에 뷰 모델에서 제공하지 않는 특수한 형식이 필요할 때가 있는데 뷰 모델이 뷰와의 양방향 데이터 바인딩에 참여하려면 해당 속성이 PropertyChanged 이벤트를 발생시켜야 한다. 뷰 모델은 INotifyPropertyChanged 인터페이스를 구현하고 속성이 변경 될 때 PropertyChanged 이벤트를 발생시키면 된다.
컬렉션의 경우 ObservableCollection<T>이 제공되며 이 경우 컬렉션 변경(삽입 또는 삭제)을 알리기 위해 INotifyChangedChanged 인터페이스를 구현하지 않아도 된다.
n 뷰는 뷰 모델을 "인식"하고 뷰 모델은 모델을 잘지만 모델은 뷰 모델을 인식하지 못하고 뷰 모델은 뷰를 인식하지 못한다. 따라서 뷰 모델은 뷰를 모델에서 분리하고 모델이 뷰와 독립적으로 전개되도록 한다.
n 뷰 모델은 모델 클래스의 어댑터 역할을 하므로 뷰의 변경에 따라 모델 코드를 크게 변경하지 않아도 된다.
n 뷰가 XAML로 완전히 구현 된 경우 코드를 건드리지 않고 앱 UI를 다시 디자인 할 수 있다.
n Model-View-ViewModel(MVVM) 패턴에 기반하여 XAML을 탄생 시켰으며 기본 패턴은 View와 Model 이다(즉 ViewModel). XAML은 사용자 인터페이스와 (*.xaml) 기본데이터(Model)와의 연결은 코드 비하인드 C#(*.cs)으로 가능하도록 완벽한 분리를 해놓았다. View와 ViewModel은 XAML XML파일의 Data Binding 정의를 통해 연결될 수도 있으며 View에 대한 BindingContext는 일반적으로 ViewModel의 인스턴스 이다.
n Xamarin MVVM 예제
4.6.1 ViewModel을 View에 연결하기
n ViewModel은 Xamarin.Forms의 데이터 바인딩 기능을 사용하여 뷰(View)에 연결할 수 있다.
n 뷰를 구성하고 모델을 보고 런타임에 연관시키는 데 사용할 수있는 많은 접근 방식이 있는데 이러한 접근법은 View 첫 번째 컴포지션과 ViewModel 첫 번째 컴포지션 이라는 두 가지 범주로 나뉘는데 View 첫 번째 컴포지션과 ViewModel 첫 번째 컴포지션 중 하나를 선택하는 것은 선호도와 복잡성의 문제이다다. 그러나 모든 접근법은 뷰가 BindingContext 속성에 할당 된 뷰 모델을 가지는 것과 동일한 목표를 공유한다.
n 첫 번째 컴포지션 View에서 앱은 개념적으로 의존하는 ViewModel에 연결하는 View로 구성된다. 이 접근법의 이점은 뷰 모델이 뷰 자체에 의존하지 않기 때문에 느슨하게 결합 된 단위 테스트 가능한 애플리케이션을 쉽게 구성 할 수 있다는 것이다. 클래스의 생성 및 연관을 이해하기 위해 코드 실행을 추적하지 않고도 시각적 구조를 따라 앱 구조를 쉽게 이해할 수 있다.
n ViewModel의 첫 번째 컴포지션에서 앱은 개념적으로 뷰 모델로 구성되며 서비스는 뷰 모델에 대한 뷰의 위치를 결정한다. 뷰 생성은 추상화되어 앱의 논리적 인 비 UI 구조에 집중할 수 있으므로 모델의 첫 번째 컴포지션 View는 일부 개발자에게 자연스럽게 느껴지며 또한 다른 ViewModel에서 ViewModel을 만들 수 있다. 그러나 이 방법은 종종 복잡하며 앱의 다양한 부분이 어떻게 만들어지고 연관되는지 이해하기 어려울 수 있다.
n 뷰 모델 및 뷰를 독립적으로 유지한다. 뷰의 데이터 소스 속성에 대한 바인딩은 해당 뷰 모델에 대한 뷰의 주요 종속성이어야 하며 특히 ViewModel에서 Button 및 ListView와 같은 뷰 유형을 참조하면 안된다.
댓글 없음:
댓글 쓰기