5. Current Solutions

5.1 Overview

This chapter introduces the three chosen solutions which are analyzed and evaluated in chapter 6. These solutions are based on the .NET Framework which is a requirement defined in this thesis. They are well known in the .NET community, yet more sophisticated solutions can be found. Some of them are mentioned in chapter 8.3. The three chosen solutions share the same idea at the core level which is to increase the modularization with a plug-in architecture.

5.2 Composite UI Application Block

The Composite UI Application Block³ (CAB) is a plug-in framework from Microsoft. It helps to write complex Windows-based applications which are built of independent components. The components can be composed together in a flexible way to form an overall coherent application. The focal point of this Application Block lies on user interface integration. The components are able to contain own UI elements which can be hosted in a Shell. The Shell is responsible to show the hosted UI elements and it defines a general layout to control their appearance. The components are able to extend some special UI elements of the Shell like the menu bar, tool bar, status bar, etc. The Composite UI Application Block is shipped as C# and VB.NET 2005 version. It requires the Microsoft .NET Framework 2.0.

Architecture

CAB heavily uses and implements design patterns which are common in the development of Windows-based applications. An overview of the CAB architecture is shown in Figure 6. The design patterns used by the blocks are presented by the elliptical shapes.

Figure 6: Patterns implemented or supported by the Composite UI Application Block [MSDN06].

WorkItem

A WorkItem is a lifetime container for visual and non-visual components. Typically, it contains all components which are necessary to handle a specific use case. The WorkItem is responsible for creating and disposing these components. Additionally, it provides an implementation of the Service Locator pattern to retrieve and register services. This is an alternative to the Dependency Injection mechanism provided by CAB.

The components managed by a WorkItem can access each other inside the container. If the container is not able to find a component, it delegates the request to its parent container. This behavior is known as Chain of Responsibility pattern [GHJV95, p. 223]. The pattern allows the accessing and using of components which are registered in parent containers. WorkItems are composed in a tree structure. A CAB application always provides a single RootWorkItem which contains infrastructure services used by the child WorkItems. Figure 7 illustrates an example for a WorkItem composition. The RootWorkItem provides two services which can be used by all child WorkItems. It creates a child WorkItem for handling a use case. This WorkItem creates two additional child WorkItems which are responsible for a second use case. These additional WorkItems are able to access the state of the first use case.

Figure 7: WorkItem hierarchy [MSDN06].

Object Builder

The Object Builder is the Dependency Injection Framework behind the Composite UI Application Block. It is responsible for wiring the independent components together. The dependencies of the components are defined by Attributes (e.g. CreateNew or ServiceDependency). The Object Builder reads these Attributes and injects the required components during the creation cycle. It supports constructor and setter injection which can even be mixed. The Object Builder can also be used programmatically without defining Attributes. The methods are provided by the WorkItem. e.g. WorkItem.SmartParts.AddNew<OfficerView>();

Nevertheless, the Object Builder is a general purpose framework. CAB provides the strategies for the Object Builder so that it knows how to interpret and react on these Attributes. The Object Builder is also used by other Microsoft products like the Enterprise Library, the Web Client Software Factory, and the Mobile Client Software Factory. The source code is included in the Composite UI Application Block. A newer compatible version can be downloaded to run in partial trust environments and it is signed by the Microsoft patterns & practices team⁴.

Shell Services

The Shell Services block in Figure 6 contains some UI integration specific services. The Workspaces host the UI elements and define their appearance. CAB already includes some prefabricated Workspaces like the TabWorkspace which shows the UI elements inside tabbed pages. The UI Extensions are services to extend exposed UI elements. For example it is possible to add menu items into the Shell’s menu bar via this service.

It is common that more than one UI element invokes the same method. An open file button can be hosted in a menu bar and a tool bar. Each of these buttons are represented by an own UI element with different appearance settings. However, both should call the same method if the user presses one of these buttons. This issue is dealt by an implementation of the Command pattern [GHJV95, p. 233]. Furthermore, the Command implementation allows the association of one UI event with multiple methods (command handlers).

Core Services

The Core Services block encloses the low level services which are provided by CAB. The event broker is a loosely coupled, multicast event mechanism for components managed by the WorkItems. The events can be published and subscribed programmatically or via attributes. The State Persistence service can be used for saving the current application state and for reloading it at the next application start-up. If the application state contains sensitive data, the Cryptography service helps to protect them. The CAB Application is an abstract class that defines the application lifecycle and contains an instance of the root WorkItem. Extension and Instrumentation can be used to monitor the lifecycle of the WorkItems.

Module Loading

In CAB the modules are a synonym to plug-ins. The Module Loading block in Figure 6 shows the Enumerator service which knows how to retrieve a list of the modules to load. By default, a XML catalog file holds this list. The Loader service is responsible for the module loading. It can use the Authentication service which only loads the modules, the user has permission for. When a module has dependencies to other modules it expresses the dependencies with the ModuleDependency attribute. Behind the surface of these services the Plug-In pattern can be found.

License

The software can be used for every commercial and non-commercial purpose without any fee. It is allowed to distribute modified versions and to combine it with own products or services. Although, the license allows the modification of the source code, it can complicate the migration to a newer version of the Composite UI Application Block. The product does not come with any warranty or guarantee from Microsoft. A specialty is that this software is only allowed to run on the Windows platform. Thus, it is not permitted to run an application built on the CAB on the Linux operating system with Mono as .NET runtime platform.

5.3 Smart Client Software Factory

The Smart Client Software Factory⁵ (SCSF) assists during the creation of a composite Windows-based application which is build on the top of the Composite UI Application Block. In this thesis the May 2007 release is used. SCSF can be seen as an extension to CAB which uses additional software assets:

• Composite UI Application Block Extensions for WPF
• Enterprise Library 3.1
• Guidance Automation Extensions (for MS Visual Studio 2005)
• Guidance Automation Toolkit (for MS Visual Studio 2005)
• Application Blocks for supporting occasionally connected clients

Software Factory

SCSF uses the concept of a Software Factory. A Software Factory is a collection of software assets, software tools and documentation. It helps to build applications that share an architecture and a feature set. In the case of SCSF it supports all composite Windows-based applications. The software assets can be reusable code components and reference implementations. The software tools can be wizards, code generators and visual designers. It is common to integrate these tools into the IDE. For example the Smart Client Software Factory provides a wizard to create a view with an associated presenter class. Typical parts of the documentation are an architecture guidance, description of common patterns, how-to topics, and an explanation of the reference application. A key concept of Software Factories is that architects can customize them to their own needs. The use of Software Factories helps to increase the consistency and quality of an application and it also boosts the productivity by reusing software assets [SCSF06].

Composite UI Application Block Extensions for WPF

This application block extends CAB with a Windows Presentation Foundation (WPF) integration layer. The layer allows the Shell to host WPF user controls in the same way as it hosts Windows Forms controls. To activate the WPF integration layer the WPFFormShellApplication can be used to initialize the Composite UI framework with the needed services. The WPFUIElementAdapter service is responsible for wrapping all WPF controls with ElementHost objects. The ElementHost class is part of the .NET Framework 3.0 and can be used in Windows Forms-based applications to host WPF controls. The WPF support, which is provided by this application block, does not include the Shell and the UI infrastructure elements. They still need to be implemented via Windows Forms controls.

License

The Smart Client Software Factory uses the same license as the Composite UI Application Block.