SVG to XAML Conversion | Standalone WPF Applications | Silverlight 3 | Project Template for Silverlight 3 | Silverlight Libraries | XAML Introduction | WPF Data Binding | WPF Styles and Templates |
20 Nov 2007: .NET Framework Version 3.5 released.
I am keen on all things data and as all the design experts say, always try to separate the data from the procedural code, in such a way that a change to the code does not impact on the data. If the data and code are entangled in an application then it becomes exceedingly difficult to have any re-use of the data in another application; so when the successor to WPF comes along you are not into a major rewrite.
WPF re-introduces the concept of data binding where traditionally a database field is bound to a text box on a Windows form. This implies a fairly static situation where the fields from the database are hardwired to the textbox fields on the screen and the only way they can change is by trawling through the database and presenting a different record on the screen. With WPF this is taken several steps further because now you can have a database changing independently of your application and have your screen being updated in realtime by the changes. For example your database could contain share prices being updated continuously which are then displayed in textboxes on your screen. WPF allows these textboxes to be bound to the database and to change in real time without any screen refreshes. Another common application is where the user can have a control which dynamically changes the display of a graph similar to the type of user controls in current Paint.NET, but this time you don't change a set of parameters, press the OK button and wait for the screen to refresh; instead you use sliders (say) to change the parameters and watch the screen change as you move the slider.
The first example I tried was concerned with binding the fields in a MySQL database to textbox fields but using XAML instead of Windows Forms. My application contained only one form and used SharpDevelop to create a new Solution involved checking File/New Solution and then in the Dialogue Box selecting C#/NET 3.0 and then selecting WPF Application. Enter the name of the Application (DataBind in my example) and you will find in the left hand panel References, App.xaml, App.xaml.cs, AssemblyInfo.cs, Window1.xaml, Window1.xaml.cs. Please note that this example barely scratches the surface of what is available and so I am assembling a few more notes after the example.
Because I wanted to bind to a MySql database I went to Project/Add Reference and added MySql.Data to the assembly References.
This looks like :
The C# code to extract the data from the database and fill the DataTable is almost identical to that for NET 2.0 except for setting the DataContext. Microsoft says that Data context is a concept that allows elements to inherit information from their parent elements about the data source that is used for binding, as well as other characteristics of the binding, such as the path. It seems you can set the DataContext in the XAML file, but it seems simpler in this case to set it within the .cs file.
The following is about as simple as I could make it, just to demonstrate Data Binding in WPF. Typically, each binding has four components; a binding target object, a target property (the text property of the TextBox), a binding source, and a path to the value in the binding source to use (note - in this simple case the Path property value is the name of the source object to use for binding). Once you have this concept then the next stage is to use DataTemplates which help to make the presentation of your data objects a lot more appealing and also assist in setting a common look across your Forms.
You will probably have noticed the DataContext is set to the contentsTable in the above example. So amongst other things the DataContext determines the data source to be used. NET 2.0 introduced the concept of BindingSource, but this became complex when dealing with multiple master/detail relationships. WPF takes the concept a stage further with a much more powerful implementation of the features required to manage these complex relationships. WPF allows the concept of a hierarchy of DataContexts and any databound control will use the DataContext that is nearest. The above example uses code to set the DataContext but I understand this can also be done from within XAML. However, althought I have read this it seems to me that when dealing with a database the best place for performing the database operations is within code - this is how the Microsoft database example is written. So this is the way I will carry on until I hear differently.
Another important concept of Data Binding, very well explained on the Microsoft site, is that of the direction of binding. Briefly, without going through all the Microsoft article, you can define 'One Way' binding where any change in the source property is reflected in the target property. 'Two Way' where any change in either source or target is reflected back to the other. 'One Way To Source' is the opposite to 'One Way' binding; so reasonably straightforward and most controls default to 'One Way' except for Text in TextBoxes which default to 'Two Way' (there are other defaults so may need to check).
'Two Way' and 'One Way To Source' bindings watch out for changes in the target value and when they occur send them back to the source. This would typically be the case for the text value in a TextBox which was being edited so that the source field gets updated.
In NET 2.0 I was never totally convinced about the best way to perform Forms validation, so I was very pleased to see an example from the excellent "WPF A Beginners Guide - Part 5" which covered amonst other things using WPF for form validation. In fact it is probably best to go to the Code Project and read this article yourself rather than carry on reading here. However, if you are still here then the following is my potted interpretation and how I used this. The first thing I gathered was that there are three methods of applying data validation as follows :-
This is used when the system encounters an exception on a form, such as finding a non integer value in an integer defined field and then allows you to intercept the exception and perform some processing in XAML. For example you could define a ToolTip and outline the TextBox red all from within XAML. This approach works when the data you want to use for update does not conform to datatype but cannot be used, if say you want to check against a range or set of allowed values or against a pattern.
This allows you to set up your own validation rules allowing you to perform range checks etc. In the example using dates I noticed that there were exception checks to ensure that it was a valid date as well as custom rules to ensure the date entered was a future date.
This is the NET 3.5 method using Linq and basically shifts the data validation back to the business objects which I guess is the right place for validation to be performed. However, for the moment I am not going down the Linq path because it is one more (large) thing to learn and I want to make sure I have a thorough understanding of XAML and its role in validation.
Basically, I just wanted to check out the validation methods for mandatory, length of alpha field and date which are fairly straightforward validation requirements.