MVVM Frameworks For .NET
- Share
-
- |
Read later
My Reading List
Model-View-ViewModel is an architectural pattern mainly used in WPF, Silverlight and WP7 development whose aim is to virtually remove all the code-behind from the View layer. Interactive Designers can focus on UX needs using XAML and create bindings to the ViewModel, which is written and maintained by application developers.
MVVM is a specific implementation of the more general Presentation Pattern. MVVM ViewModel comprises of conceptual models rather than data models, and all the business logic and other operations are done within the Model and the ViewModel. There are many Frameworks which enable this. Some of them are -
Open Source
- PRISM – provided by Microsoft. Works with MEF/Unity for dependency injection, has composite commands and is extensible. Detailed tutorials and walkthroughs at MSDN.
- MVVM Light Toolkit – has Project and Item templates for Visual Studio and Expression Blend. Read more here and refer tutorials on working with VS and Expression Blend.
- Caliburn Micro – supports ViewModel-First and View-First development, Asynchronous programming through co-routines.
- Simple MVVM Toolkit – provides VS Project and Item Templates, Dependency Injection, support for Deep cloning and Property Association between Model and ViewModel
- Catel – includes Project and Item templates, user controls and enterprise library classes. Supports Dynamic View Model injection, lazy loading of view models and validations. Also sports WP7 specific view model services
Closed Source
- Intersoft ClientUI – paid – supports only WPF and Silverlight, although, apart from MVVM framework, it also provides several other features.
- Vidyano – free but not open source. Has Entity mapped/virtual Persistent Objects (data containers), business rules and in-built ACL based security
For an introduction to MVVM, refer to the following material -
- Understanding MVVM Pattern and Deep Dive MVVM by Laurent Bugnion
- Understanding the MVVM Pattern in Silverlight Applications by the MS Silverlight team
- Presentation Pattern – presentation by Erik Lebel on InfoQ
One of the biggest benefits of using MVVM is the separation of concerns, so that the UX designers and the Application developers can work in parallel. On the other hand, concerns are that it is an overkill for simpler UI operations, data-bindings are somewhat harder to debug and potential performance issues if large number of bindings are used.
Adding Valued Content
by
J B
have we really sunk to this kind of journalism?
i'd either pull this article or beef it up with some real content.
Re: Adding Valued Content
by
Roopesh Shenoy
The idea was to introduce MVVM in the context of .NET and provide various frameworks that support this. However, per your feedback, I have added more details about each of the frameworks, as well as links to additional educational content. Hope you find this useful.
Signs you might be doing MVVM wrong:
by
Jonathan Allen
View-models are not supposed to be wrappers around models. The job of a view-model is to broker requests for external services such as the loading and saving of data. The data itself, as well as validation and most of the business logic, should be in the models.
I can’t emphasize this enough. Whenever you create a view-model that wraps a model by delegation you introduce a huge hole in your API. Specially, anything with a direct reference to the model can change a property in such a way that the view-model and thus the UI are never notified. Likewise, any changes to calculated fields in the model won’t be propagated back to the view-model.
2. You have a view and a view-model with the same name.
Ideally view-models are agnostic to the screens they are used by. This is especially true in a WPF application where multiple windows may be sharing the same instance of a view-model.
For smaller applications such you may only need a single view-model for the whole application. For larger applications you may need one for the main functionality and one for each secondary aspect such as configuration management.
3. You have no code behind.
In absolute terms code behind is neither a good nor a bad thing. It is merely a place to put logic that is specific to a single view or control. So when I see a view with no code-behind at all I immediately check for the following mistakes:
* Does the view-model touch specific controls by name?
* Is the view-model being given access to controls via a command parameter?
* Is EventToCommand or another leaky behavior being used in place of simple event handler?
EventToCommand from MVVM Light is especially bad because it will prevent controls from being garbage collected after they are removed from the screen.
4. View-models are listening to property changed notifications
If a model has a longer life-span then the view-model that listens to its events then you probably have a memory leak. Unlike views which have an unloaded event, view-models don’t have a good story for life-cycle management. So if they attach an event to a model that may out-last them then the view-model will be leaked.
Re: Signs you might be doing MVVM wrong:
by
Geert Depickere
When you say "view-models ... wrappers around models", are you talking about the approach you often see where an instance of a Model is put in a View-Model property and the view then binds directly to the properties of that instance?
In that approach, it looks like you are doing data binding to the View-Model but in reality you are binding to the Model (proof of that is that the databinding no longer works if e.g. you rename one of the properties of the Model class...).
It this is what you are referring to, I totally agree. If so, can you elaborate on the alternative?
Re: Signs you might be doing MVVM wrong:
by
Jonathan Allen
What concerns me is code like this:
public string FirstName
{
get { return _customer.FirstName; }
set
{
if (value = = _customer.FirstName)
return;
_customer.FirstName = value;
base.OnPropertyChanged("FirstName");
}
}
source: msdn.microsoft.com/en-us/magazine/dd419663.aspx
Bugs I see all the time:
1. Someone directly changes _customer.FirstName. Since the change wasn't done via the CustomerViewModel the UI is not notified about the change.
2. Changing _customer.FirstName has the side effect of updating _customer.FullName. Again, CustomerViewModel doesn't know it happened so it cannot notify the UI.
Given how incredibly error prone this style is, there is simply no way to justify it. I'm not sure what Josh Smith was thinking when he write the MSDN article, but has done a great disservice to the developer community.
Re: Signs you might be doing MVVM wrong:
by
Roopesh Shenoy
Flex has a much better UI binding model - as long as the properties you create are declared as bindable, the UI gets updated automatically when the property return values get updated (even if its a complex property with a lot of logic before returning a get value). That's much simpler for the developer.
For eg. (just ignore for a moment that I declared a public variable) the following simple component displaying the customer's name just works, even if you modify the customer name, or just pass a new customer object to this component.
<?xml version="1.0" encoding="utf-8"?>
<s:BorderContainer>
<fx:Script>
<![CDATA[
[Bindable]
public var customer:Customer = new Customer();
]]>
</fxScript>
<s:Label text="{customer.Name}" />
<BorderContainer></BorderContainer>
I can easily imagine how this can be refactored to look more like the MVVM pattern, but the point is, the UI takes care of the property changes and doesn't need special events to be thrown. </
Concurrency in Clojure
Stuart Halloway May 17, 2013
Confessions of an Agile Addict
Ole Friis Østergaard May 16, 2013
Web Development: You're Doing It Wrong
Stefan Tilkov May 16, 2013
Programming The Feynman Way
Ben Evans May 15, 2013
Hello stranger!
You need to Register an InfoQ account or Login to post comments. But there's so much more behind being registered.Get the most out of the InfoQ experience.
Tell us what you think