Page 2 of 2   « previous page

WorkItems may contain state. The State class is essentially a name/object collection that can be used to store any state data that needs to be maintained during the life of the WorkItem and that needs to be available for any of the SmartParts contained inside that WorkItem.

WorkItems and their child SmartParts must live in some sort of UI shell. CAB provides base classes on which to build a number of different types of Windows application interfaces, which are called "workspaces." The current implementation gives you the following workspace types:

• Window - a standard window
• MDI - Multiple Document Interface
• Tab - A window with tabs to switch between views
• Deck - Similar to a deck of cards, SmartParts are layered on top of one another and can be opened, closed, and/or reordered by the controller
• Zone - A tiled interface like Microsoft Outlook, with multiple zones that can interact with one another

ComponentModel
While the primary visible deliverables of CAB are related to Windows Forms and the Model/View/Controller pattern, much of the value of CAB is in its implementation of the Dependency Injection design pattern in the Microsoft.Practices.ComponentModel namespace. The Microsoft.Practices.ComponentModel namespace is declared outside the Microsoft.ApplicationBlocks namespace because it was designed to be available for use in many patterns & practices releases in the future, including non-Application Block releases. The classes in this namespace form a component architecture based on the Dependency Injection/Inversion of Control design pattern and Dependency Injection containers.

Dependency Injection is a pattern that was originally developed in the Java community and represents a specific application of the Inversion of Control pattern. The definition given in the CAB documentation is, "A pattern that enables reuse and loose coupling of components through the injection of component dependencies at run time." For an in-depth introduction to Dependency Injection, take a look at Martin Fowler's article at www.martinfowler.com/articles/injection.html. The basic idea of Dependency Injection is to design your software to work with objects that are as self-contained as possible and have very basic, generic interfaces, and to determine the details of what each object really is at run time based on the needs of the specific implementation.

The best way to illustrate how CAB uses Dependency Injection is with an example that uses WorkItems. A WorkItem is defined to require a specific set of SmartParts to do its job (complete its use case). This example consists of a use case for a billing system that states that Customer Service users will modify customer profile records (see Figure 1). The WorkItem that models this use case requires a SmartPart that displays a form for entering customer information in the UI.

Based on the requirements for this billing system, the SmartPart used to enter customer information differs significantly for different types of customers. An industrial customer, for instance, uses a significantly different set of controls and fields than a government customer does. In addition, new types of customers are added all the time, and much of the time a new type of customer means a new SmartPart must be developed and added to the UI.

CAB handles this type of situation easily, at least from the UI perspective, using Dependency Injection. All the WorkItem knows about or cares about is that it must have an "EnterCustomerInfo" SmartPart inside it - this is its "dependency." The specific SmartPart that will be inserted into the WorkItem by the application (and subsequently displayed in the UI) will be determined by the type of customer. The mapping of the generic container to the specific object can be done either in code or in configuration. The insertion of the specific implementation of the SmartPart into the generic, reusable "Create New Customer Record" WorkItem is an example of Dependency Injection.

Publish/Subscribe Events
Another powerful pattern implementation is the Publish/Subscribe events. Essentially, event handlers on one object are set up to handle events that take place on other objects. This can be very useful in complex user interfaces, and is essential in a loosely coupled architecture like CAB, where clicking on a control in one part of the UI must be able to have an effect on any number of other portions of the interface.

Objects that need to know when an event fires in another object will "subscribe" to that event. This is done in CAB by placing the "EventSubscription" attribute on an event handler method on each object that needs to know when a specific event is fired (C#):

[EventSubscription("event://EventName", EventScope.Global)]
public void HandleExternalEvent(object sender, EventArgs args)

The events that are published will be intercepted by the EventBroker service and all subscribers will have their handlers fired and be passed the appropriate event arguments. Publishing is done by marking an event declaration with the EventPublication attribute as follows (C#):

[EventPublication("event://EventName", EventScope.Global)]
public event MyGlobalEventHandler EventName;

Note that the specific event is defined in the attributes using the URI "event://EventName," and that in the examples above the EventScope is set to global. You can also set the EventScope to "WorkItem," which allows you to publish events that will only be handled by objects that are inside the same WorkItem container.

Application of Generics
CAB provides an immense amount of guidance in the form of examples of how to implement new .NET 2.0 features, such as generic typed collections. One particularly interesting implementation is the generic factory method overloads on the Microsoft.Practices.ComponentModel.CompositeContainer class.

All Dependency Injection Container classes inherit from this base class, which defines a bare-bones object that is a container itself and can also be a component in a parent container. This class has some methods defined that are "generic factories." The methods look like this (C#):

public T Create(string name) where T : new()

The "T" is a type placeholder. It represents the type of object that is being instantiated and returned by the factory method. It is both the return type, and also the type specified by the calling entity in the generic "typeparam" (the type name inside the "<>" characters when the method is called).

The "where T : new()" portion of the method declaration is a compiler constraint. It tells the compiler that whatever type "T" represents in any given call of this method, it must have a public constructor that takes no parameters.

This type of factory method provides an immense amount of decoupling - it's essentially an "everything factory." In the "CompositeContainer" implementation, this method creates the new object and then inserts it into its own internal generic Dictionary<string, object>, so you can use the class to create and insert objects of any type into itself. Note that the string name parameter passed into the factory method is not actually passed on to the constructor of the new object; it is used as the key for the container's internal Dictionary.

Summary
I have really just brushed the surface of some of the content and guidance included in CAB - it has a really broad scope and provides a tremendous amount of reference material and useful pattern implementations. More content and functionality will be added to it, including UI process navigation abstraction similar to that provided by the UI Process Application Block, either when it is officially released or incrementally thereafter.

There is great potential to go along with the somewhat-daunting learning curve, however, and the ideas and concepts are creative and smart and well worth the study.

Resources

• CAB community Web site: http://practices.gotdotnet.com/projects/cab
• Microsoft patterns & practices: http://msdn.microsoft.com/practices/
• Martin Fowler on Dependency Injection: www.martinfowler.com/articles/injection.html

Page 2 of 2   « previous page