The development process of a user control in WPF
WPF offers the possibility to create/customize your own UI user control. To make an ideal user control, the correct development process plays a quite important role. One of the starting points of WPF is to separate the jobs of developers and designers. WPF can really help you do that, but only if you follow certain process, otherwise, your UI user control will still be a messy mixture of functionalities, styles and animations. Before we set up a development process, we should have a clear mind of how a UI user control is constructed. Here I am gonna show you the structure in the point view of development.
In a WPF project, a UI control consists of a XAML file and a code-behind C# file. Generally we can say, the XAML file is about the look&feel of UI control and the C# file is about the functionalities. To be more specific, we can still define such following responsibilities each of the files should have.
The XAML file:
As I said, XAML takes care of the look&feel of a user control. The look&feel is nothing else but how the control looks like(look) and the how the control interacts with users(feel). To map these in the context of WPF, they are styles and animations. But that is not all yet. A user control should have a skeleton, based on which the styles and animations can work. This skeleton is called Control Template in WPF’s terminology. A control template specifies which atomic controls this user control consists of, and how they are arranged in the layout. Beside the control template, the data template should be in consideration as well, if the user control is somehow data-bound with certain data source. The data template will play the role of constraining which data should be presented in the control.
The C# file:
The C# file is considered to be “code-behind”, which means they are the functioning codes behind the “scene”. It should have nothing to do with the appearance of the control in front, as the XAML file has nothing to do with the functionalities. This is the raw line. The real and more specific contents can be overloaded constructors, the regular properties, the dependency properties, data binding and all the functions, equipped with the control. Based on my understanding, I would say, the purpose of these functions are more about the I/O interfaces with the backend business logic, and interactions with other controls. Of course you can also add more things in there if appropriate.
Note: A rule of thumb is , if you start the creation of the UI user control in Blend, do not define the structure in the control XAML, but in the control template in the resource dictionary, because the structure in the control XAML will be anyway written over if you later apply the control template on it.
Based on the above understanding of WPF UI user control, we can set up the development process, and distribute the work separately on designers and developers. Apparently, this is no more a difficulty job.
In my practice in Siemens UE department, we have three different roles to work on one user control. They are:
UI developer — taking care of the control template, data template and data binding in Blend and VS2005.
Designer — working on the styles and animations in Blend.
Developer — mainly implementing the above addressed C# work in VS2005.
I will probably later contribute a sample to demo the working of the process. In the sample, you can see the separation of designers and developers can be really clean, and the integration of the jobs can also be very seamless.
As for the detailed collaboration and teamwork of the three roles, I will probably post another entry later.