Introduction

With this article, I want to show some basic techniques to achieve 2-way databinding in a WPF/XBAP application.

I do not intend to clarify "huge" architect principles like NTier separation into DataLogic, BusinessLogic and UILogic (as you should be aware of as a professional developer ...), but I wanted to make things in this article as simple as possible and focus on the basic "DataBinding" principles in what may be needed by a simple XBAP/WPF application.

In this article, I will demonstrate the creation of a simple administration program for the "Category" table of the NorthWind database. The purpose of this small XBAP/WPF program is to visualize the categories, and let the user add/delete or modify category objects. Finally, I've added some sorting and filtering possibilities.

Background

The reader is supposed to have some background knowledge about databinding in WinForms, connecting to a SQL-Server dataBase and a brief knowledge of XAML.

Using the Code

1. The Model

First of all, we have our "Model" class, which in this case is an ADO.NET EntityFramework Entity Data Model, just containing our Categories class, as needed by the example.

To add some custom behaviour, I've created an override of the "Categories" partial class:

It's a good habit to foresee a custom method for object creating, other than letting the programmer use the standard new object() method. For this reason, I've put the base class constructor as private and provided a Create() method to add a new category. As you can see from the code, I've added some custom behaviour, like creating an empty image for each newly created category. I've also added the _isNew property, this is needed by the persistence code, when we're going to persist the newly added object to the database.

Within our startup page (Page1.xaml), we have to initialize our data access object, namely a static reference to our NorthWindEntities, next we need some lists of type Categories to hold track of our loaded and during the session deleted Categories objects, and finally we need a CollectionView which makes a sorted and/or filtered view of our binded data.

First, we're going to load our categories into our _categoryList collection. Next we set the DataContext of our Page to our categories collection and create a view to our data. This view points to the default view of our collection, and in this way, navigation, sorting and filtering our collection is made possible. We also create some sorting properties that can be used to create a sorted view of our data. Finally, if something changes in our collection, like a user is navigation or filtering, or sorting, we want the UI to be updated.

Navigating our data, thus moving from one category to another ... , is a common behaviour of our application. I've coded the First, Prev, Next and Last buttons to point our data to the first, previous, next or last category of our list. Also notice that the CurrentChanged handler we created on our view will be triggered each time the user "hits" one of the previous buttons. This notification will update our recordpointer display in the UI.

By means of the sort properties added in the beginning, sorting a CollectionView is quite easy to achieve. I've also added a simple filter, namely CategoryName. The filter code is a bit more of a challenge. In this case, I've created a filter class filtering the objectlist on the searchtext as supplied by the user and next sets the record pointer to the first object in the list and refreshes the UI.

First we get the current item for our view and add it to the deleted items list (needed for persistence -> see later). Next we remove the object from our current list and position to the next record if any.

Data persistency for saving the data ... is quite an easy process in EF! All SQL-Related Commands, Adapters, Connections parameters and so on, are hidden for the user, so quite readable code can be written to persist our data. The comments in the code above are self-explanatory, I think!

9. Final Words

So, thanks for reading! Hope you enjoyed it. And of course ... once more, in a professional environment, certainly in case of large projects, you should separate your code in layers, abstracting data-access in a DataLayer, UI binding and validation though a BusinessLayer, and so on ... but for educational reasons, I just kept this application as simple as possible!

Share

About the Author

Working in the IT-Branch for more then 15 years now. Starting as a programmer in WinDev, moved to Progress, shifted to .NET since 2003. At the moment i'm employed as a Microsoft Dynamics AX Interfacing Architect at RealDolmen (Belgium). In my spare time, i'm a die hard mountainbiker and together with my son Jarne, we're climbing the hills in the "Flemish Ardens" and the wonderfull "Pays des Collines". I also enjoy "a p'tit Jack" (Jack Daniels Whiskey) or a "Duvel" (beer) for "l'après VTT !".

Comments and Discussions

I am new to entity framework and this article is awesome for me as it helps me understand the entity f/w better.
However, I wonder how it will fit with a WPF application using the MV-VM pattern?
Any examples/samples/articles/videos you have or know about?

Concerning LINQ to SQL vs. Entity Framework (LINQ to Entities), i also had some troubles to
understand the real difference, as, these are both ORM tools.

But I think the difference is the mapping principle, as LINQ to SQL is restriced to 1-1 mapping
of your relational database, in contrast to EF which makes it possible to create a domain model
which differs from what your relational-DB may look like.

On the other side, both principles show data in terms of "custom objects" instead of some DataSet.

I personaly think EF is a replacement for LINQ to SQL for the future. It's somewhat the same product,
started as LINQ to SQL, and enhanced to EF.