The Model View ViewModel (MVVM) is an architectural pattern used in software engineering that originated from Microsoft as a specialization of the Presentation Model design pattern introduced by Martin Fowler.
Why MVVM & Why not MVC or MVP:
In the MVC pattern, the Model is the data, the View is the user interface, and the Controller is the programmatic interface between the view, the model, and the user input.
This pattern, however, does not work well in declarative user interfaces like WPF or Silverlight. Reason, the XAML that these technologies uses can define some of the interface between the input and the view (Using Data Binding, Triggers, and states can be declared in XAML).
Model-View-Presenter (MVP) is another common pattern for layering applications.
In the MVP pattern, the presenter is responsible for setting and managing state for a view.
Like MVC, MVP does not quite fit the Silverlight model because the XAML might contain declarative Data Binding, Triggers, & State Management.
So where does that leave us?
Luckily for Silverlight , the WPF community has rallied behind a pattern called Model-View-ViewModel (MVVM).
This pattern is an adaptation of the MVC and MVP patterns in which:
· The ViewModel provides a data model and behavior to the View. This allows the View to declaratively bind to the ViewModel.
· The View becomes a mix of XAML and C#.
· The Model represents the data available to the application, and
· The ViewModel prepares the Model in order to bind it to the View.
Note: As the MVVM pattern is designed to support WPF and Silverlight, this pattern is only newly Available To The Public, as opposed to MVC or Model View Presenter (MVP).
MVVM:
Largely based on the MVC pattern, MVVM is targeted at modern UI development platforms (WPF & Silverlight).
MVVM pattern designed to gain two things.
· The advantages of separation of functional development provided by MVC
· And leveraging the advantages of XAML and the WPF, by binding data as close as possible to the Model while using the XAML. Thus minimizing the need for "code behind," especially in the View
· MVVM was designed to make use of specific functions in WPF & Silverlight, to better facilitate the separation of View layer development from the rest of the pattern.
· This is done by removing virtually all "code behind" from the View layer.
· Instead of requiring designers to write View code, they can use the native WPF markup language XAML and Create Bindings To The Viewmodel, which is written and maintained by application developers.
· This separation of roles allows designers to focus on UX needs rather than programming or business logic, allowing for the layers of an application to be developed in multiple work streams.
Elements of the MVVM pattern are described as below - Also similartiies with MVC.
| | |
| Model | As in the classic MVC pattern, the model refers to either (a) An object model that represents the real state content (an object-oriented approach), or (b) The data access layer that represents that content (a data-centric approach). |
| View | As in the classic MVC pattern, the view refers to all elements displayed by the GUI such as buttons, windows, graphics, and other controls. |
| ViewModel | The ViewModel is a "Model of the View" that serves in data binding between the View and the Model. The View-Model of MVVM is responsible for exposing the data objects from the Model, in such a way that those objects are easily consumed in XAML. It is similar to the Controller (in the MVC pattern) that acts as a Data Binder that changes Model information into View information and passes commands from the View into the Model. The ViewModel exposes public properties, commands, and abstractions. |
| Controller | some references for MVVM also include a Controller layer or illustrate that the ViewModel is a specialized functional set in parallel with a Controller, while others do not. This difference is an ongoing area of discussion regarding the standardization of the MVVM pattern. |
Criticism
There are currently three main areas of criticism regarding the MVVM pattern.
1. MVVM currently lacks standardization from Microsoft both in implementation and in toolsets
2. The overhead in implementing MVVM is "overkill" for simple UI operations. Also for larger applications, generalizing the View layer becomes more difficult.
3. Moreover, data binding, if not managed well, can result in considerable memory consumption in an application.
4. Exercise in creating large numbers of data bindings to the ViewModel results in duplicate code and maintenance problems.
Hope this helps.
Thanks & Regards,
| Arun Manglick Digital Group InfoTech Pvt. Ltd. Pyramid building, Plot No.5 Rajeev Gandhi InfoTech Park, Phase I, Hinjewadi, Pune - 411057, India Office: +91 20 66532084 Fax: +91 20 66532052 Mobile: +91 9850901262 |
No comments:
Post a Comment