Karsten Januszewski and Jaime Rodriguez in The New Iteration (http://windowsclient.net/wpf/white-papers/thenewiteration.aspx) point out the ability of WPF infrastructure (framework and tools) to allow for clear separation between the roles of designers and programmers. They also describe various development workflows this separation supports. I have been experimenting with an approach that separates the roles further and provides more detailed workflow definition.
The approach allows five distinct roles to cooperate in the development process: architect, developer, designer, tester and UI stylist:
Architect defines the main components of the UI in terms of class interfaces and how they relate to each other. He/she breaks down the application into Views, Presenters and Data providers. Views will be implemented as User Controls or Windows, Presenters and Data Providers as regular, non-WPF specific classes. The definition is expressed as one or more VS.NET projects containing the definition of these interfaces.
Tester defines the unit tests and test cases exercising these interfaces.
Developer writes the code implementing the above interfaces, providing both UI specific and business specific logic (in separate classes).
Designer determines the layout logic, i.e. the type of layout containers and controls needed. It’s important that the designer limits his/her work to just the choice of the type of controls and how they contain each other NOT to their actual sizing or placement in terms of margins/paddings/widths, etc. That work will be done later by the UI Stylist. The Designer also uses data-binding to define data movement between the UI and the Presenter interfaces defined by the Architect. He/she also adds the references to the events exposed by the View interfaces.
UI Stylist completes UI design primarily in terms of esthetics and usability: adds layout parameters (e.g. margins, min/max sizes, alignments), modifies appearance of controls (styles, templates) and other parameters which do not affect the functionality (particularly code) of the application. UI Stylist creates Resource Dictionaries.
This approach uses the following concepts typically found in UI applications: View, Presenter, and Data Provider (references to Silverlight are to Silverlight 2 beta).
View is a class derived from a FrameworkElement (usually UserControl); it is usually compiled from XAML and code-behind. The View class exposes WPF/Silverlight events using a WPF/Silverlight-independent delegate. These are then consumed by the Presenter, which in turn uses them to operate on the Data Provider. There is a 1:1 relationship between a View and a Presenter, although both may in turn be broken down into other Views and Presenters.
Presenter is a class that marshals data from and to data providers. It shields the View from knowing the data provider format and behavior and vice versa. It usually has no knowledge of WPF or Silverlight, though it may make use such generic classes as Brushes for colors. In this approach, the View creates the relavant presenter as its Data Context at load time.
Data Provider is a class or collection of classes that handle movement of data to and from the application (to database, WCF service, etc.).
This development approach is broken into five steps.
Factor applications into views, presenters and data providers. Use .NET interfaces to identify their properties, events, methods.
VS.NET Class Diagram
Generate empty classes supporting these interfaces
VS.NET Implement Interface
Complete development of above classes. Assumes that the View creates and saves a reference to appropriate Presenter in the View’s data context.
VS.NET C#/VB.NET class library development
(parallel with above)
Design user controls implementing the above views: identify layout containers and place controls within them (DO NOT SPECIFY LAYOUT DETAILS, e.g. Left/Right/Size/Margin – make them Auto). Set the View’s Data Context to a new instance of appropriate Presenter. Use databinding to move data between the view and related presenter. Associate relevant event handler names (defined for each view) with events exposed by individual controls.
Integrate output from 3a and b: i.e. replace empty classes developed in 2 with those developed in 3a, and test.
VS.NET Test Edition
Add style definitions to application and/or individual user controls. Insert them into appropriate resource bags. These Styles need to define, among others settings for margins/min/max sizes, etc. needed to change the “compact” layout from 3b into final, user-friendly layout.
This approach allows clear separation of responsibilities between different roles involved in the development: each role works on a different VS.NET project or source file, using tools specialized for the role. Each role can develop and focus on different skills and know-how: architetural and functional requirements, UI layout, code and appearance. Much of the work of each role can be done in parallel to the others.
I am now experimenting with how best to use Command pattern in this approach. If this first attempt at blogging does not lead to my emotional ruin, I may write some more.