News

If you don’t use the Composite WPF libraries but still want to implement the Presentation Model (aka Model-View-ViewModel) pattern then you should take a look at the WPF Application Framework (WAF).

Project Description

This project provides a new reference implementation for the Composite WPF libraries. During the development of this reference implementation I have extracted some useful classes into a new library called ‘Composite Extensions’.



The Test Suite reference implementation was originally developed for the Composite UI Application Block. You might already know this application from one of the Websites:

• Diploma Thesis: Evaluation of Plug-In Architectures for a Test Suite
• CodePlex: CAB Extension / Test Suite reference application
• CodePlex: Smart Client Contrib

I have ported this application to use WPF instead of Windows Forms and the Composite Application Guidance for WPF instead of the Composite UI Application Block. The migration work was very informative because it showed me that by using separated interfaces and dependency injection the time and effort for porting the application to a new application framework was really low. Quite another story was the migration from Windows Forms to WPF. It took me a lot more time to recreate the User Interface layer in WPF because I had to learn the new concepts of WPF first.

Highlights

Composite Extensions library

for Composite Application Guidance - Feb 2009 release

• IApplicationContainer and ApplicationContainer: New façade that includes methods to register types at the container. This new container façade allows me to decouple the Test Suite from the Unity Framework.
• ApplicationInfo: Provides Information about the running application (e.g. Product Name, Version Number).
• DelegateCommand: Simplifies the command usage.
• ResourceService: Includes helper methods to handle WPF resources. Furthermore, it provides an attached property to define shared resource dictionaries inside the View.
• WeakEventManagerBase: Derive from this class to support new event types for the WeakEvent pattern.
• TypeManager: Provides a method to retrieve the PropertyInfo through a type-safe lambda expression. This can be used to pass property names to the property changed notifications implementation.
• PresentationModel, IView and Model: These classes support you to implement the PresentationModel pattern.
• ToolBarTrayRegionAdapter: An adapter for the RegionManager that allows a module to host new toolbars in the shell.

Test Suite reference implementation

• Separated presentation through Presentation Model (often referred as Model-View-ViewModel pattern).
  • The Composite Extensions library contains the PresentationModel base class and the IView interface that helps to implement the Presentation Model pattern.
  • Collaboration with the model is done through weak events. This ensures that no memory leaks occur. See: RtfEditor.Module / RtfEditorPresentationModel.cs or Help.Module / HelpPresentationModel.cs (here is a custom WeakEventManager used)
  • Composition of views that uses a separate PresentationModel for every view. See: TestDevice / FGenDevice.ControlView / Views: ConfigurationView.xaml is used by ConfigurationEditWindow.xaml and FunctionGenView.xaml
• Document Management (New, Open, Save and Close documents): The Infrastructure.Module / Services / DocumentManager and the RtfEditor.Module shows how document management could be handled in a composite application. The DocumentManager service handles document lifecycle tasks and keeps track of all registered document types. This service mediates between the user interface and the document. A module developer, who has to implement a new document type, does not have to care about things like configuring the OpenFileDialog component or enabling and disabling the save buttons.
• Enterprise Library example modules: The three modules LogViewer.Module, LogViewer.Demo and Message.Demo are dedicated to show how the Logging Application Block and the Exception Application Block works.
• Modules deployment: The Test Suite reference implementation provides every module a separate directory to avoid file naming or versioning conflicts between the modules. These directories are found under the directory Modules. The Libraries directory contains all the libraries used by the Test Suite and its modules (e.g. Enterprise Library). By using sub directories, the CLR has to be told where it is going to find the assemblies. The Shell adds the probing element in the application configuration file (App.config) to accomplish this.

Documentation

A description of the Test Suite reference implementation can be found in my diploma thesis. But be aware that the diploma thesis describes the old Test Suite reference implementation which uses the Composite UI Application Block.

Discussions

• Best Practices: How to implement INotifyPropertyChanged right?
• Best Practices: How to handle shared resources in a modular application?
• Best Practices: Localize a WPF application
• Best Practices: How to implement ShortCut Keys with DelegateCommands
• Best Practices: Should I create own assemblies for module interfaces?