Chapter 1. B. Solution Architecture: Loose Coupling with CAB

B. Solution Architecture: Loose Coupling with CAB

1. We can solve these architectural problems by developing an application from loosely coupled parts. Instead of compiling everything together into one giant .exe file, we can build the parts more or less separately and stitch them together ("Compose them") at runtime using services provided by the Composite UI Application Block (CAB).

   This approach allows our application to be based on the concept of modules or plug-ins. Because of loose coupling, there are fewer interactions between the parts, making our application not only easier to develop initially, but also easier to extend and maintain than a classic monolithic application. It also allows development teams to work independently—for example, the user interface specialists concentrating on presentation and the business logic teams on business logic, as shown in Figure 1-3.

    

   Figure 1-3. An application developed from loosely coupled parts.

   [View full size image]

   

2. We've seen this sort of architecture before in any number of modular designs. The key improvement that CAB provides is a prefabricated infrastructure that supports this loose coupling. For example, instead of having to know at compile time which class is responsible for firing an event (announcing, say, the user has selected a patient from a list or a search), CAB allows us to easily write code that says, "Whenever the event with the name PatientSelected is fired, no matter who does it, call this response function to tell me about it because I care." Or "Whichever object is in charge of implementing the interface IWhatever, give me a reference to it because I need it to get my work done." Or "Take this control and show it in the display windows whose name is [this] so the user can see it, please." CAB makes extensive internal use of .NET Reflection to provide these capabilities. The services that CAB provides for accomplishing these tasks are listed in Table 1-1, along with the lesson in which each is described.

    

   Table 1-1. Location in this Book of CAB Functionality for Solving Loose Problems of Loosely Coupled Applictions.

   Problem	CAB Infrastructure	Chapter
   Central control of modules loaded at runtime by a specific user	Module enumerator and loader services	2
   Connection to programmatic services	Service infrastructure	2
   Connection of logical subapplications to each other within a composite application	WorkItem mechanism and dependency injection	3
   Display of visual controls created by subapplications	Workspaces (container frames) and SmartParts (controls container with those frames)	4
   Different subapplications sharing main menu, toolbar, and status bar	User interface extension sites	5
   Notifying and being notified of events	Publish and subscribe event broker service	6

   
   

3. Table 1-2 identifies the main terms we will be using in our discussion of CAB, listed in the order in which you're likely to think about them. A sample CAB application is shown in Figure 1-4, illustrating some of the concepts.

    

   Table 1-2. Definitions of Basic Terms Used in a CAB Application

   Shell Application	The main Windows Forms application, the outer container of all parts of a CAB application.. The Shell Application manages the CAB startup process.
   Shell Form	The main window of the Shell Application. The generic term Shell used on its own usually means Shell Form, although not always. It usually contains Workspaces and user interface elements such as menus and toolbars
   Workspace	The container window for a SmartPart owned by a WorkItem;. The Workspace can control how the SmartPart is displayed or hidden. The CAB provides several standard Workspace classes, and you can also write your own.
   WorkItem	A runtime container of the objects and services used by a discrete part of a CAB application. Think of it as a logical sub-process or sub-application. It is the basic unit of software scoping in a CAB application. Your business logic lives in one or more WorkItems.
   SmartPart	A visual presentation, a view, of the data owned by a WorkItem; it is owned by a WorkItem and displayed in a Workspace. A SmartPart is usually implemented as a Windows Forms User Control, often containing other Windows Forms controls. Besides displaying the data of a WorkItem, it often allows the user to modify it.
   Service	A supporting class that provides programmatic functionality to other objects in a loosely coupled way. It usually contains utility methods that are not tied to a specific work item.
   Module	A .NET assembly that provides the physical container for WorkItems, services, and their supporting classes.

   
   

    

   Figure 1-4. Application diagram of shell, smartparts, and workspaces.

   [View full size image]

   

4. There really is nothing new under the sun.

   Although they use different underlying technologies, the architecture of a CAB application reminds me very much of in-place activation in Object Linking and Embedding. While not a perfect or complete analogy (OLE-embedded objects rarely if ever talk to each other, while CAB items often do), if you think of things that way, your user-level understanding of OLE will help you quickly grasp the roles of the components of CAB. Consider the archetypal case of an Excel spreadsheet embedded in a Microsoft Word document as shown in Figure 1-5. The CAB analogy would be as shown in Table 1-3.

    

   Figure 1-5.

   [View full size image]

   

    

   Table 1-3. CAB Equivalents of Common OLE Functionality

   CAB Item	OLE Equivalent
   Shell Application	Word, the running program
   Shell Form	Word's main window
   Workspace	The area on Word's main window in which Word allows Excel to display its editing window
   SmartPart	The editing window created by Excel
   WorkItem	Excel's business logic
   Service	OLE libraries
   Module	The physical file containing the business logic code, Excel.exe

   
   

5. The original CAB library code is available on the MSDN Web site, currently at http://msdn.microsoft.com/library/en-us/dnpag2/html/cab.asp. It comes in a set of three source code projects, named CompositeUI, CompositeUI.WinForms, and ObjectBuilder. They all live in the solution CompositeUI.sln, the default location of which is C:\Program Files\Microsoft Composite UI App Block\CSharp. See Figure 1-6.

    

   Figure 1-6. CAB DLL projects.

   

   The solution builds three dynamic linked libraries (DLLs), named

   • CompositeUI.dll

   • CompositeUI.WinForms.dll

   • ObjectBuilder.dll

   The easiest place to find them all is in the CompositeUI.WinForms\bin\Debug or \Release folder, as shown in Figure 1-7.

    

   Figure 1-7. CAB DLLs built in a project folder.

   [View full size image]

   

6. You will have to decide early on in your project exactly how you want to distribute these DLLs. If you make every CAB application require its own private copy of them, then you can bundle the whole thing up and download it via ClickOnce. This is fast and easy and hard to get wrong. The only disadvantage is that you will then have extra copies of them. They aren't very large, about 300KB total, so perhaps this isn't too bad.

   Alternatively, you could sign them with your strong name and place them in the Global Assembly Cache GAC. However, this means that ClickOnce won't be able to put them there because it can't modify the GAC.