These two 1-hour videos show step-by-step how to use the MVVM pattern to build simple quiz applications in both Silverlight and WPF:
Implementing Model-View-ViewModel in Silverlight
Implementing Model-View-ViewModel in WPF
What amazes me about these is how different they are structurally, for instance, how they use DataBinding:
In the Silverlight approach, we set the DataContext of a View to an ObservableCollection in the ViewModel:
<views:QuestionView x:Name="QuestionDataView" />
QuestionViewModel qdata = new QuestionViewModel();
qdata.FetchQuestions();
QuestionDataView.DataContext = qdata.Questions;
In the WPF approach, we set the DataContext of the Window to the ViewModel itself.
<view:QuizView Margin="4" />
base.DataContext = new QuizViewModel(Quiz.Create());
It just seems that every MVVM example I look at does DataContext binding in a slightly new variation and I'm trying to nail down some solid ground as to "how DataContext binding is done in the MVVM pattern".
What goes through your head when you decide to bind the DataContext to something: why bind the DataContext of a Window / View / ListBox / etc. to a ObservableCollection / ModelView / etc.? What are the advantages, disadvantages, strategies here?
Any input appreciated.
MVVM – WPF Data Bindings Data binding is the key feature that differentiates MVVM from other UI separation patterns like MVC and MVP. For data binding you need to have a view or set of UI elements constructed, and then you need some other object that the bindings are going to point to.
DataContext is the head of everything. It makes sure that your View is hooked up with ViewModel. There are 3 ways to hook-up View with ViewModel. Within XAML. Code-Behind.
The DataContext is the source of all entities mapped over a database connection. It tracks changes that you made to all retrieved entities and maintains an "identity cache" that guarantees that entities retrieved more than one time are represented by using the same object instance.
Every FrameworkElement can be associated with a DataContext which will be used as the default data source during binding, if no other data source is specified in the binding code. Also, the children of this FrameworkElement auotmatically inherit this setting.
Did they mention why the different approach was used for Silverlight? It may just be a limitation of the platform.
The recommended approach is to absolutely use the view model itself as your view's DataContext
. In fact, rather than creating the view explicitly, you should be creating the view model and have WPF resolve the view for you. To do so, register a DataTemplate
:
<DataTemplate DataType="{x:Type local:MyViewModel}">
<local:MyView/>
</DataTemplate>
Then you just stick your view model instance into a ContentControl
, ItemsControl
or whatever and WPF will render it with the appropriate DataTemplate
. That DataTemplate
will have the view model as its DataContext
, by virtue of WPF's templating system.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With