The patterns & practices group at Microsoft provides architectural and design guidance for users of Microsoft technologies. Part of the way they do this is by producing and distributing packages called "application blocks." An application block consists of a functional subsystem or software framework that can be valuable in several ways. Application blocks can be implemented in many types of applications as time-saving subsystems. They are also reference examples of software designed and developed using the best practices of Microsoft architecture. Application blocks are freely distributed with all source code and documentation.

The Composite User Interface Application Block
The Composite UI Application Block (called "CAB" in the online community) is the first application block that has been developed exclusively for .NET 2.0. It is an architectural framework that is designed to help developers quickly implement loosely coupled Windows Forms applications. It employs a number of industry standard design patterns, including Model/View/Controller, Inversion of Control/Dependency Injection, and Publish/Subscribe.

Dependency Injection is a design pattern that was originally developed in the Java community. The basic idea of Dependency Injection is to design software that consists of a number of highly cohesive modules that have predefined interfaces, and to determine the details of how the objects interact with one another at run time. A great in-depth article on Dependency Injection by Martin Fowler can be found at www.martinfowler.com/articles/injection.html.

The goal of this article is to provide a straightforward introduction to CAB that focuses on its implementation of Dependency Injection. It will do this by providing step-by-step instructions for the construction of a simple Windows Forms application.

The demo application that will be built is a very simple master/detail data viewer. The interface will consist of two list boxes. The list box on the left side of the form will display a set of categories. Clicking on one of the items in this list box will cause line items in that category to be displayed in the list box on the right. The sample data we will use will be a set of shopping lists stored in an XML file.

CAB Installation and Prerequisites
The CAB installation package can be downloaded from the Microsoft patterns & practices Web site. In order to install CAB, you must have the .NET 2.0 Framework installed on the development machine. This walkthrough assumes that you will be using Visual Studio 2005 and C# for development.

Create the Shell Application
Open Visual Studio 2005 and create a new project of type "Windows Application." Name the project "DataViewerShell" and change the name of the solution to "ListManager."

Before starting to code we need to bring the CAB assemblies into the solution. You can add references to the compiled assemblies directly, if you have already built CAB, or you can just include the projects in your solution. The CAB assemblies that are used for this walkthrough are: "CompositeUI," "CompositeUI.Utility," "CompositeUI.WinForms," and "ObjectBuilder."

After you have included the CAB assemblies, the first step is to create the shell form. Right-click on the project and add a new Windows Form. Name it "ShellForm.cs." To fulfill the requirements of our sample application, we will need two list boxes to show up on this form: one for the master data on the left and one for the details on the right. Using CAB however, the only thing we will do in the shell is to create placeholders (called "Workspaces") where the controls will reside.

A workspace is a type of control that is included in CAB. If you want to use the designer to add workspaces to the shell form, you may want to load them into the toolbox. Bring up the toolbox if it is hidden or closed, scroll to the bottom, right-click in the "General" section, and select "Choose Items." In the "Choose Toolbox Items" dialog, click on "Browse" and navigate to the location of the "Microsoft.Practices.CompositeUI.WinForms.dll" assembly. Click on this assembly and click "OK," and the CAB workspace controls should load up into your toolbox.

For this example, the type of Workspace we will use will be a DeckWorkspace. This type allows stacking of multiple controls in the same place, like a deck of cards, only displaying the one on top. Drag two DeckWorkspace controls onto the shell form and arrange them as shown in Figure 1. Name the workspace on the left "navigationWorkspace," and the one on the right "viewerWorkspace."

The only actual coding we need to do in the shell is to create the application itself. Add a new class to the project and name it "ShellApplication.cs." This class will define the application object that launches and hosts the shell form. The only thing you need to do to wire this application up for CAB is to have it inherit from "Microsoft.Practices.CompositeUI.WinForms.FormShellApplicaiton<TWorkItem, TShell>."

The type declaration for FormShellApplication<TWorkItem, TShell> takes in two types. TWorkItem is the type of the default WorkItem, which is a basic container class in CAB. The default WorkItem for this shell doesn't need to have any special code in it, as it just acts as an overall container, so we can pass the type "WorkItem," which is the base class. TShell represents the type of the shell form. For TShell, we will specify the type of the shell form that we just created, "ShellForm."

The final step is to add the default static void Main() method to launch an instance of the application. Listing 1 shows the code for the complete ShellApplication class. The base FormShellApplication class does all of the work for us upon initialization: it creates an instance of the default work item and launches an instance of the ShellForm.

The application should build and run at this point. Check in the properties of DataViewerShell that the output type is "Windows Application," then compile and launch the application in the debugger. You should see a blank ShellForm like the one shown in Figure 2.

Create the First Module
CAB provides base container classes called "Modules," which represent sets of related controls and functionality. Using Dependency Injection, modules can be plugged into a shell at run time. CAB user controls are called "SmartParts," since they are context-aware controls that participate in Dependency Injection. The first module we will create for the demo application will be the one that will house the ListBox on the left side of our shell.

Add a new project of type "Class Library" to your solution and name it "ListOrganizerModule." Add references to the four CAB assemblies, but not to the shell application project. The List Organizer module needs three classes in it; one for the user control that holds the ListBox, a WorkItem class to act as a container for injection into the shell, and a class that inherits from the ModuleInit class to house initialization code for the module.

First, create a new User Control and name it "ListOrganizerListBox." In the Visual Studio Designer, drag a ListBox control onto the user control and name it "listBoxLists." This user control will be inserted into the navigationWorkspace on the shell form. Resize the control so that it is approximately the size of the navigationWorkspace.

Next, create the WorkItem. Add a new class to the project, and name it "ListOrganizerWorkItem." Modify the class declaration so that it inherits from Microsoft.Practices.CompositeUI.WorkItem. All we need to do in this class is to write an overload of the "Run" method that takes in the workspace where we want the control to show up. The code for this is shown in Listing 2.

The overload of the "Run" method takes in a parameter of type IWorkspace. It calls the "Show" method on the IWorkspace, passing in a new instance of the ListOrganizerListBox user control. The new instance is created by calling the AddNew<TType> generic factory method on the WorkItem's "Items" property. This method creates an instance of the specified type, injects it into the WorkItem, and returns a reference to it.

Finally, we need to create the ModuleInit class (see Listing 3). This class is the default implementation of IModule, which is the interface that defines a module. Add a new class to the project and name it "ListOrganizerInit.cs." Modify the class declaration so that it inherits from Microsoft.Practices.CompositeUI.ModuleInit.

Add a private member and public property for the parent work item. Mark the property with the "ServiceDependency" attribute - doing this will cause CAB to automatically initialize the value when the application starts.

Override the Load method of the ModuleInit class to load our module into the shell. This override does three things. First, it calls the Load method on the base class. Second, it creates an instance of the ListOrganizerWorkItem class using the generic factory method on the parent work item's collection of work items. Finally, it calls the overload of "Run" on the ListOrganizerWorkItem that we created in that class, which loads our user control into the correct workspace on the shell form.