Introduction
I recently started a project where in order to bind to properties within the Code section of UserControl (or Window), they were using DependencyProperty definitions, in fact sometimes it was even worse, they were also deriving from INotifyPropertyChanged, and using the OnPropertyChanged.
Many people consider code within the Code section of a XAML document bad, and that only in rare instances will I put code into the Code section, preferring to create a behavior, which can be reused.
There are times when it is necessary to use DependencyProperty definitions, but seldom in a UserControl.
Difference between DependencyProperty and INotifyPropertyChanged
The following was published by "LBugnion":
INotifyPropertyChanged has advantages over DependencyProperty definitions:
- This is more lightweight
- Allows you more freedom in modeling your objects
- Can be serialized easily
- You can raise the event when you want, which can be useful in certain scenarios, for example when you want to bundle multiple changes in only one UI operation, or when you need to raise the event even if the data didn't change (to force redraw...)
A DependencyProperty has the following advantages:
- Callback mechanism (almost) for free, allowing notification when the property value changes
- Coercion mechanism allows you to define rules for max, min and present value of the property
- It is faster: Optimizing Performance: Data Binding
There are apparently other considerations. The consensus is that DependencyProperty definitions are great for controls (and you can implement a CustomControl), but for data objects, you should implement INotifyPropertyChanged.
Doing the Binding to the Window/UserControl
I saw the following when looking at the code in the project:
public UserInputControl()
{
InitializeComponent();
LayoutRoot.DataContext = this;
}
Although this is fine, I really prefer to do this in XAML.
You can actually do the setting of the DataContext in XAML, if there is a separate class that is associated with DataContext for a XAML file, I will do the following:
<Window.DataContext>
<local:ViewModel/>
</Window.DataContext>
Normally, I will use this method of associating a ViewModel with a View only for sample projects. The nice thing about this technique is that it creates an instance of the ViewModel and automatically assigns it to the DataContext of the View.
Maybe you think you could use this method for associating the DataContext with the class itself. NO!!! When you try to use the XAML above for the class itself, a new instance of the XAML and class is created, and that creates a new instance of the XAML and class again. This happens recursively so you run out of memory.
The following XAML is one way to associate the DataContext with the class itself:
<Window x:Class="DataContextToSelfSample.MainWindow"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
xmlns:local="clr-namespace:DataContextToSelfSample"
xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
DataContext="{Binding RelativeSource={RelativeSource Self}}"
Title="MainWindow"
Width="400"
Height="300"
mc:Ignorable="d">
What is happening is that the RelativeSource of the Binding is being used with the RelativeSource as Self.
History
- 04/09/2018: Initial version
