An Introduction to the Smart Client Software Factory and Composite Application Block: Part 2 WorkItems

Introduction

In part 1 of this article I introduced a simple example of how to use Microsoft’s Composite Application Block. To try to keep the example as simple as possible I only covered modules and shells.

There are two other core concepts that you need to understand to be able to use even the most basic functionality of the CAB. These are WorkItems, and dependency injection. This part of the article will discuss WorkItems, and part 3 will discuss dependency injection.

WorkItems – Basic Concepts

Microsoft’s documentation defines a WorkItem as ‘a run-time container of components that are collaborating to fulfill a use case’. In many ways the best way to think of them is as classes that contain collections of other classes that are logically grouped together. The name is a little strange: ‘work items’ in general tend to be individual tasks that need to be performed in, say, a workflow, or, in the .NET Framework, in a thread pool. The WorkItems in the CAB are broader than that.

In code terms WorkItems are just objects of type ‘WorkItem’ (a class in the Microsoft.Patterns.CompositeUI library). Each WorkItem has collection classes associated with it to allow it to ‘contain’ components. Three of these collection classes that are reasonably easy to understand are:

1. The Items collection, which can contain almost anything since it’s a (special) collection of System.Objects
2. The Services collection, which is a collection of CAB services.
3. The WorkItems collection, which is a collection of other ‘child’ WorkItems.

However there are several other collections of CAB code objects on the WorkItem class. WorkItems also have state (used to track changes), and status (active/inactive).

Container Hierarchy and the Root WorkItem

There’s a second important aspect of WorkItems: they can be arranged into a hierarchy. This hierarchy typically starts with a root WorkItem that contains components (code objects) and other WorkItems, the other WorkItems again can contain components and other WorkItems, and so on.

This is particularly useful since we can construct the hierarchy across modules, even though the individual modules may not reference each other. We can then use the WorkItem hierarchy to use components in other modules.

I’ll show exactly how this works in a minute, but in our example from part 1 we could add a WorkItem class to each of our three projects. We could then instantiate one WorkItem object per project at runtime. The WorkItem object in the Shell program could be a root WorkItem. It could contain the other two WorkItems.

If we add a component from the Shell project to the root WorkItem we can access that from, say, the Red application’s WorkItem by simply using this.ParentWorkItem.Items[“ComponentName”].

One obvious difficulty with this approach is that we are then tightly-coupling our two modules together to some extent, which is what we were trying to avoid by not having direct dependencies between our modules. However, as we’ll see we can still release new versions of each module independently of the rest of the code.

WorkItems and the FormShellApplication

In part 1 of this article we saw that to start a CAB application we inherit from FormShellApplication<,>. We provide two types when we declare the new class to close the generic definition:

    public class Program : FormShellApplication<WorkItem, Form1>
    {

As we have seen the second of these (Form1) is the shell for the application and gets instantiated and shown at start up (when we do new Program().Run()). The WorkItem also gets instantiated at start up. This will be the root WorkItem for the application, sitting at the top of the hierarchy described above. It can be referred to in the Program class using the RootWorkItem property (this.RootWorkItem).

To be continued in part 3.