MVVM의 기본 개념-ViewModel은 무엇을해야합니까?

MVVM의 기본 개념-ViewModel은 무엇을해야합니까?

---

MVVM의 개념을 이해하기 위해 이미 여러 블로그를 읽고 몇 가지 프로젝트를 살펴 보았습니다.

내가 이해하는 바에 따르면 View 는 멍청한 것이고 전달되는 것을 제시하는 방법을 알고있을뿐입니다.

모델 은 단순한 데이터 일 뿐이며 ViewModel 은 둘 사이의 패딩처럼 작동하는 것으로, Model 에서 정보를 가져 와서 View로 전달 해야 하며, View 는이를 표시하는 방법을 알아야합니다. 또는 반대로 View 의 정보가 변경되면 변경 사항을 Model 에 전달해야합니다 .

그러나 나는 여전히 개념을 적용하는 방법을 모릅니다. 누군가 내가 개념을 이해할 수 있도록 매우 간단한 시나리오를 설명 할 수 있습니까? 저는 이미 여러 프로젝트를 살펴 봤지만 여전히 완전히 이해가되지는 않습니다. 그래서 누군가가 평범한 영어로 작성할 수 있다면 좋을 것입니다.

---

나는 이것을 이렇게 생각하고 싶다.

당신이 말했듯이 조회수는 멍청합니다. MVVM에 대해 자주 링크되는 MSDN 기사 를 작성 하는 Josh Smith 는 뷰가 "데이터가 입는 옷"이라고 말했습니다. 뷰는 실제로 데이터를 포함하거나 직접 조작하지 않으며 뷰 모델의 속성 및 명령에 바인딩됩니다.

모델은 비즈니스 개체에서와 같이 애플리케이션의 도메인 을 모델링 하는 개체입니다. 애플리케이션이 뮤직 스토어입니까? 아마도 모델 개체는 아티스트, 앨범 및 노래 일 것입니다. 애플리케이션이 조직도 브라우저입니까? 아마도 모델 개체는 관리자와 직원이 될 것입니다. 이러한 모델 개체는 어떤 종류의 시각적 렌더링과도 관련이 없으며, 적용하는 응용 프로그램과도 직접 관련이 없습니다. 모델 개체는 어떤 종류를 나타내는 개체군으로서 자체적으로 완전히 이해되어야합니다. 도메인의. 모델 계층에는 일반적으로 서비스 접근 자와 같은 것이 포함됩니다.

이것은 우리를 Viewmodels로 가져옵니다. 그들은 무엇인가? GUI 애플리케이션 을 모델링 하는 객체입니다.즉, 뷰에서 사용할 데이터와 기능을 제공합니다. 빌드하는 실제 애플리케이션의 구조와 동작을 정의합니다. 모델 개체의 경우 도메인은 선택한 도메인 (음악 상점, 조직도 브라우저 등)이지만 뷰 모델의 경우 도메인은 그래픽 응용 프로그램입니다. 뷰 모델은 애플리케이션이 수행하는 모든 동작과 데이터를 캡슐화합니다. 그들은 객체와 목록을 속성으로뿐만 아니라 명령과 같은 것들로 노출 할 것입니다. 명령은 단순히 동작 (가장 간단하게 메서드 호출)을 전달하는 개체에 래핑 된 것입니다.이 아이디어는 시각적 컨트롤을 개체에 연결하는 데이터 바인딩에 의해 뷰가 구동되기 때문에 중요합니다. MVVM에서는 버튼에 Click 핸들러 메서드를 제공하지 않습니다.

저에게 가장 혼란스러운 부분은 다음과 같습니다.

• 뷰 모델은 그래픽 응용 프로그램의 모델이지만 시각적 개념을 직접 참조하거나 사용하지 않습니다. 예를 들어 ViewModels에서 Windows 컨트롤에 대한 참조를 원하지 않습니다. 이러한 항목은 뷰에 표시됩니다. ViewModels는 단순히 데이터와 동작을 컨트롤 또는 바인딩 할 다른 개체에 노출합니다. 예를 들어-ListBox가있는 뷰가 있습니까? 귀하의 뷰 모델은 거의 확실하게 어떤 종류의 컬렉션을 가질 것입니다. 보기에 버튼이 있습니까? 당신의 뷰 모델은 거의 확실하게 몇 가지 명령을 가질 것입니다.
• "뷰 모델"로 간주 될 수있는 몇 가지 종류의 개체가 있습니다. 이해하기 가장 간단한 종류의 뷰 모델은 "화면 XYZ에는 텍스트 상자, 목록 상자 및 세 개의 버튼이 있으므로 뷰 모델에는 문자열, 컬렉션, 그리고 세 개의 명령. " 뷰 모델 레이어에 맞는 또 다른 종류의 객체는 동작을 제공하고 뷰에서 더 유용하게 만드는 모델 객체를 둘러싼 래퍼입니다. 여기에서 "두꺼운"뷰 모델 레이어와 "얇은"뷰 모델 레이어의 개념을 살펴볼 수 있습니다. "얇은"뷰 모델 계층은 모델 객체를 뷰에 직접 노출하는 뷰 모델 세트입니다. 즉, 뷰가 모델 객체의 속성에 직접 바인딩됩니다. 이것은 간단한 읽기 전용보기, 그러나 각 개체와 관련된 동작을 원하면 어떻게해야합니까? 모델은 애플리케이션과 관련이 없으며 도메인과 만 관련이 있기 때문에 모델에서 원하지 않습니다. 모델 개체를 래핑하고 바인딩 친화적 인 데이터와 동작을 제공하는 개체에 넣을 수 있습니다. 이 래퍼 객체는 뷰 모델로도 간주되며, 뷰 모델 레이어가 "두꺼워 진"뷰 모델 레이어가됩니다. 뷰가 모델 클래스의 어떤 것에 직접 바인딩되지 않습니다. 컬렉션에는 모델 자체를 포함하는 대신 모델을 래핑하는 뷰 모델이 포함됩니다. 모델 개체를 래핑하고 바인딩 친화적 인 데이터와 동작을 제공하는 개체에 넣을 수 있습니다. 이 래퍼 객체는 뷰 모델로도 간주되며, 뷰 모델 레이어가 "두꺼워 진"뷰 모델 레이어가됩니다. 뷰가 모델 클래스의 어떤 것에 직접 바인딩되지 않습니다. 컬렉션에는 모델 자체를 포함하는 대신 모델을 래핑하는 뷰 모델이 포함됩니다. 모델 개체를 래핑하고 바인딩 친화적 인 데이터와 동작을 제공하는 개체에 넣을 수 있습니다. 이 래퍼 객체는 뷰 모델로도 간주되며, 뷰 모델 레이어가 "두꺼워 진"뷰 모델 레이어가됩니다. 뷰가 모델 클래스의 어떤 것에 직접 바인딩되지 않습니다. 컬렉션에는 모델 자체를 포함하는 대신 모델을 래핑하는 뷰 모델이 포함됩니다.

토끼 구멍은 더 깊어집니다. MVVM이 작동하도록하는 ValueConverters와 같은 많은 관용구가 있으며, Blendability, 테스트 및 앱에서 데이터를 전달하는 방법과 같은 것에 대해 생각하기 시작할 때 적용 할 많은 관용구가 있습니다. 각 뷰 모델은 필요한 동작에 액세스 할 수 있지만 (여기에서 종속성 주입이 발생합니다) 위의 내용이 좋은 시작이되기를 바랍니다. 핵심은 시각적 요소, 도메인, 실제 애플리케이션의 구조와 동작을 세 가지로 생각하는 것입니다.

---

이 매우 유용한 기사 를 소스로 사용하여 View , ViewModel 및 Model에 대한 요약입니다 .

---

전망:

• 보기는 창, 페이지, 사용자 정의 컨트롤 또는 데이터 템플릿과 같은 시각적 요소입니다. 보기는보기에 포함 된 컨트롤과 시각적 레이아웃 및 스타일을 정의합니다.

• 뷰는 DataContext속성을 통해 뷰 모델을 참조합니다 . 뷰의 컨트롤은 뷰 모델에 의해 노출 된 속성 및 명령에 바인딩 된 데이터입니다.

• 뷰는 뷰와 뷰 모델 간의 데이터 바인딩 동작을 사용자 정의 할 수 있습니다. 예를 들어 뷰는 값 변환기를 사용하여 UI에 표시 할 데이터의 형식을 지정하거나 유효성 검사 규칙을 사용하여 사용자에게 추가 입력 데이터 유효성 검사를 제공 할 수 있습니다.

• 뷰는 뷰 모델의 상태 변경 또는 UI와 사용자의 상호 작용을 통해 트리거 될 수있는 애니메이션 또는 전환과 같은 UI 시각적 동작을 정의하고 처리합니다.

• 뷰의 코드 숨김은 XAML에서 표현하기 어렵거나 뷰에 정의 된 특정 UI 컨트롤에 대한 직접 참조가 필요한 시각적 동작을 구현하는 UI 논리를 정의 할 수 있습니다.

참고 :
뷰 모델에는 뷰의 특정 시각적 요소에 대한 명시 적 지식이 없어야하므로 뷰 내에서 시각적 요소를 프로그래밍 방식으로 조작하는 코드는 뷰의 코드 숨김에 있거나 동작에 캡슐화되어야합니다.

---

모델보기 :

• 뷰 모델은 비 시각적 클래스이며 WPF 또는 Silverlight 기본 클래스에서 파생되지 않습니다. 애플리케이션에서 사용 사례 또는 사용자 작업을 지원하는 데 필요한 프레젠테이션 논리를 캡슐화합니다. 뷰 모델은 뷰 및 모델과 독립적으로 테스트 할 수 있습니다.

• The view model typically does not directly reference the view. It implements properties and commands to which the view can data bind. It notifies the view of any state changes via change notification events via the INotifyPropertyChanged and INotifyCollectionChanged interfaces.

• The view model coordinates the view's interaction with the model. It may convert or manipulate data so that it can be easily consumed by the view and may implement additional properties that may not be present on the model. It may also implement data validation via the IDataErrorInfo or INotifyDataErrorInfo interfaces.

• The view model may define logical states that the view can represent visually to the user.

NOTE:
Anything that is important to the logical behavior of the application should go into the view model. Code to retrieve or manipulate data items that are to be displayed in the view through data binding should reside in the view model.

---

Model:

• Model classes are non-visual classes that encapsulate the application's data and business logic. They are responsible for managing the application's data and for ensuring its consistency and validity by encapsulating the required business rules and data validation logic.

• The model classes do not directly reference the view or view model classes and have no dependency on how they are implemented.

• The model classes typically provide property and collection change notification events through the INotifyPropertyChanged and INotifyCollectionChanged interfaces. This allows them to be easily data bound in the view. Model classes that represent collections of objects typically derive from the ObservableCollection<T> class.

• The model classes typically provide data validation and error reporting through either theIDataErrorInfo or INotifyDataErrorInfo interfaces.

• The model classes are typically used in conjunction with a service or repository that encapsulates data access and caching.

---

I've written this out in about as "plain english" as I can think of in this series on MVVM. In particular, this diagram is likely the simplest, short explanation.

That being said, basically, the "model" is your data or business rules. It really shouldn't know about how or where it's going to be used, and especially not which technology is going to use it. The "model" is the core guts of the application - and it shouldn't need to worry about whether the application is WPF, Silverlight, Windows Forms, ASP.NET, etc - it's just "itself" in a pure form.

The "View" is the part that is completely technology specific. In MVVM, ideally, the View should be nearly 100% XAML, as this provides some huge gains for flexibility.

However, there needs to be something that translates the information from the Model into some form where it's usable by the technology at hand - this is where the ViewModel comes into play. For example, this often "wraps" up the model classes into a "ViewModel" for that specific data that includes Commands (for running logic), implements INotifyPropertyChanged (for data binding support), etc. That's it - it's the bridge that makes the Model usable by the View.

---

A great intro to MVVM can be found in Jason Dolinger's video here. I kept the video with me for quite a while when I was starting, it's really useful.

---

Building a ViewModel that presents a consistent facade over the underlying Model can be a lot more complex than it looks. This article about building ViewModel objects demonstrates how to build a ViewModel, and illustrates some of the issues your likely to encounter - along with what look like reasonable solutions. When I read it the section on dealing with collections was missing, but its still got some interesting points.

참고URL : https://stackoverflow.com/questions/5421874/basic-concepts-of-mvvm-what-should-a-viewmodel-do