This is what I'm trying to do:
- I'm writing a
UserControl
that I want to be consumed by other developers. I want end users to be able to use my control using Dependency Properties.
<lib:ControlView ControlsText={Binding Path=UsersOwnViewModelText} />
I'm using the MVVM pattern.
I'm binding my ViewModels to their View's using
<DataTemplates>
<DataTemplate DataType="{x:Type local:ControlViewModel}"> <local:ControlView /> </DataTemplate>
So I have two questions:
Am I right in thinking that if a UserControl is being consumed in XAML then the UserControl must set the ViewModel as its
DataContext
when the control'sLoaded
event fires instead of using the<DataTemplate>
method?How do I allow users to data bind to my control's dependency properties while still being data bound to my ViewModel?
Basically, instead of binding your UserControl's datacontext to the userControlViewModel, it's better to do it on the first child element of the user control. That way, all the references that you make within the control will be bound to the userControlViewModel, but the dependencies properties can be set from the data context set where you want to use your UserControl.
This is from a project I'm working at:
Then on the code behind:
Then when you use this on your main view, you can set the dependency property with the value you want to pass to MyUSerControl
A
UserControl
is part of the "View" in "MVVM" just like theTextBox
orListView
controls are part of the View.Whether you decide to use MVVM to develop your
UserControl
itself or write it in QBASIC (not recommended) it does not break the MVVM pattern for the consumers of yourUserControl
so long as they can do every thing they need with yourUserControl
by binding toDependencyProperty
's exposed on yourUserControl
. i.e. YourUserControl
should expose the properties it is dependent upon (hence the name). Once you grasp thisDependencyProperty
's suddenly make a whole lot of sense and you want their helpful on changed event handlers and default values you specify in their constructor.If your
UserControl
is in a different assembly or not I cannot see how that makes a difference.That said many would advocate you build your
UserControl
using the MVVM pattern itself for all the good reasons MVVM brings e.g. helping another developer looking at your code. However some things simply are not possible and/or much harder more complex and less performant hacking the XAML to do this - I am not talking about your garden variety Add User Form but for example aUserControl
handling the layout of thousands of visuals. Furthermore since you are working in your View you do NOT want yourUserControl
's ViewModels mixed in with you applications!Basically I am saying it is well within MVVM not to use MVVM on your View!
You should separate the two use cases:
Importantly, the latter depends on the former - not vice versa.
Use case 1 would use dependency properties, template bindings, all the things that go into making a regular WPF control:
MyControl.cs:
Generic.xaml:
You would then define use case 2 as:
MyViewModel.cs:
MyView.xaml:
Best of both worlds with a clean separation. Other developers depend only on the control, which could (and probably should) be in a completely different assembly than your view model and view.
First off, I don't think MVVM is a good choice if you are developing a UserControl that will be consumed by others. A lookless control is what you really should be developing. Jeremiah Morrill has a blog post about this subject.
With that said, you can set the datacontext with XAML if you have a default public constructor.
Inside ControlView.xaml put: