In this second article, I’d like to share my coding conventions for WPF development, hoping to get some feedback that I can integrate back into it.

In order to do so, let’s define the terms first that are used in the diagram below:

View
A View is the actual user interface presentation and might have a different look& feel from target device/audience.  I.e. the functionality is the same but a Phone application has a total different design from a Windows app. The view’s concerns are:

1. To display and to update the ViewModel data that is bound to UI Components. For example,  a TextBox that is bound to a string Property.
2. To react to UI events by executing Command methods in the ViewModel. UI Events are caused by the user interacting with the user interface in any form. Examples are Button clicks or events in a Drag & Drop scenario.
3. To react to ViewModel Notifications by changing the states of UI Components. These notification events cannot be modeled as Properties, but Views still need to know about them. Because a ViewModel does not know about the Views that are consuming the notifications, ViewModels broadcast the events and Views will register to receive the Notification messages. For example, enabling a play button, after the ViewModel has sent a notification that the media is loaded and ready.

ViewModel
All ViewModels encapsulate some application state or data, exposed as properties. They also exposed the behavior as Commands, implemented as methods, to handle UI Events. In addition, ViewModels will broadcast Notification messages of events that cannot be modeled as Properties.
ViewModels communicate with Domain Services to execute business logic and to retrieve (Domain) Models. Examples of Domain Services are RIA Services, Entity Framework Services, custom Web Services or even Stored Procedures.

(Domain) Models
(Domain) Models are in most cases just DTOs (Data Value Objects) that contain data values exposed as Properties.  In the case that DTOs implement the INotifyPropertyChanged events, they can be bound directly to the UI Components; otherwise the ViewModel will need to include a two-way mapper from its own bindable Properties to the DTO Properties.  The newest version of Entity Framework creates now Entities that are bindable.
 

Implementation Conventions
This section defines where what code resides in order to achieve a clean separation of concerns:

View
A View in WPF is made up of two components: the UI Markup which is the XAML and the UI Logic what is referred to as the code behind. Because of its complexity, XAML is edited exclusively with Expression Blend. All data binding and all events to command execution mapping is done in XAML through Blend.
The code behind contains the constructor to initialize the UI Components and all the UI Message Handlers; nothing else. The code behind has direct access to the UI Components and can implement state changes on those elements. Depending on the View implementation it can decide to react to Notification Message or not.

ViewModel
ViewModels are designed according to Use Case specifications without having a specific User Interface in mind. Simply stated, all data element in the use cases are translated into Properties and all actions are implemented as Command methods of the ViewModel. In addition, the implementation is supported by a set of Unit Test Cases and can be built in parallel to the Views.

Domain Service / Model
Ideally, the domain specific implementation is already available or is the midst of development, so that at least the interface of the services and the Domain Models themselves are defined. System Analysts will then map the UI Use Cases to the appropriate Service calls and models, so that the developer can quickly implement the Commands in the ViewModels.
Note: It is good practice to implement an adapter or proxy pattern in between the Domain View and the Services.