System.Windows + XAML
Simple binding. 3 alternate ways to bind the business object to the presentation.
Using only C# [
The typical approach is pretty cumbersome. The same result can be achieved by implementing the INotifyPropertyChanged interface in the
Examinee class to generate an event everytime the value in the object’s property changes. I have highlighted portions in code listing 4 that need to be added to implement INotifyPropertyChanged.
With the above approach then you do not need to gather data changes from the business object but you do need to implement event handlers to move data from the user interface properties to the business object and delegate to handle the property changed events from the business object.
Using C# and XAML [
INotifyPropertyChanged and XAML]
Both the approaches described above were used with typical Windows applications, although I created the form using XAML. The final approach (and the right one at that) uses the Data Binding syntax in XAML, and would show you how easy it is to bind UI elements directly to an object that implements
In this article, you’ll see how to use the IDataErrorInfo interface implementation, ValidationRules, BindingGroups, exceptions, and validation-related attached properties and events to address your data-validation needs. You’ll also see how to customize the display of validation errors with your own ErrorTemplates and ToolTips.
I’m talking about WPF Validation Rules. Validation Rules are objects that apply validation over a data Binding operation, and they are added to the Binding.ValidationRules Collection. They can be created by deriving from the ValidationRule class and overriding its Validate method that should hold the validation logic. Then, normally, you would add the rule to the collection in your xaml code, through property element syntax, or in code.
Although not a part of this article, there’s another validation mechanism built into WPF. You can also test one’s input through an ExceptionValidationRule, which invalidates a value if there are exceptions during source updates of the binding source property. You can even provide custom logic to specify how the binding engine handles these exceptions by using a UpdateSourceExceptionFilterCallback.
In the previous article I’ve shown how to apply Validation Rules to controls in order to prevent/access user input. In the process, user was warned through a visual change in the target control. It’s the simplistic and direct way of doing validation and works perfectly from the UX point of view. However, from the developer point of view, a better implementation is required to ease the quantity of code needed and to isolate concerns.
The idea is to apply validation rules by means of an attached property, in which the owner would have the reference to the control and its target Dependency Property, and the required logic to add the rule object implicitly.
Simplify validation code by subclassing the Binding.
So what’s the trick when we wish to replace the good old Binding class by a custom one? The Binding class, like many others also familiar to you like StaticResource, DynamicResource, RelativeSource or Templatebinding, is a MarkupExtension. You can detect MarkupExtensions in XAML by the curly braces. They are the actual indicator of a markup to the XAML parser. So the idea here is to create a new binding-like MarkupExtension and extend it to accommodate binding functionality with built in validation.