The Composite UI Application Block (CAB) is all about writing loosely coupled plug-in modules for Smart Client apps. What happens when someone has written a module and you want to enhance its behavior without modifying the original code? You write a WorkItemExtension.
First a little background. A WorkItem represents a particular use case, like editing a customer, for example. As a container for the use case, it contains a view and a presenter. In the bank teller sample, the CustomerWorkItem displays a CustomerView that allows the user to edit customer data. Now someone else comes along and they want to display additional information to extend the original use case. Of course, subclassing the CustomerWorkItem would not work because there would be no way to tell the original caller of the work item (probably a ModuleInit) to run your subclass instead of the parent. Instead, they would write a CustomerWorkItemExtension to extend the CustomerWorkItem without modifying original CustomerWorkItem code. The WorkItemExtension hooks into all the events of the extended WorkItem (Initialized, Activated, Deactivated, Terminated). The code looks like this:
[WorkItemExtension(typeof(CustomerWorkItem))]
public class CustomerWorkItemExtension : WorkItemExtension
{
protected override void OnActivated()
{
WorkItem.Workspaces[workspace].Show(aditionalView);
}
}
Notice that the attribute defines which workitem we are extending and that the WorkItem member variable in this code snippet is the extended WorkItem (CustomerWorkItem in our example).
Another cool trick is to extend your work item base class and include logging or performance metrics for all your work items. The Smart Client Software Factory does this for infrastucture testing.This is a simple example of Aspect Oriented Programming.
Clik here to view.
