Composite UI Application Block 学习笔记
1. 概念（Concept）
1.1. SmartParts
SmartParts provide the visual elements in your applications. These visual elements can be entirely independent of the application in which they are hosted, which allows them to be developed independently as well.
Extension：
A SmartPart is built by laying out .NET form components and making a unit of interaction that can fulfill a segment of the use case.
1.2. Workspace
A Workspace is the container and manager for a SmartPart. It can control how the SmartPart is displayed or hidden and how it is laid out. You can create and use the following types of Workspaces:
1.3. WorkItems
图 1‑1 主要对象和模式
A WorkItem is a run-time container of components that are collaborating to fulfill a use case. It contains the following code and classes:
1) Start-up (or initialization) code that initializes the use case
2) State that is shared by components collaborating in the use case
3) Controller classes that act on the state and other resources
4) View classes that interact with their controllers and reference state
5) Tear-down code
Extension：
A WorkItem is a unit of work that helps to complete a use case. In most cases, there are five components which compose a WorkItem. These are the visual aspect, the business logic controller, the business entities (customer, account, and so on), services, and state.
During its lifetime, a WorkItem drives the use case by showing or hiding appropriate views. A WorkItem can be composed of other nested WorkItems, each of which can have its own state. This state is analogous to ASP.NET session state.
You can use special persistence techniques to save WorkItems and then restore them later.
WorkItems encapsulate object collaborations for a specific use case, typically using the Model-View-Controller(MVC) pattern. The WorkItem supports the MVC pattern through the following:
1) Model. This is represented by a WorkItem state.
2) View. WorkItems may contain one or more views.
3) Controller. Each view has associated controllers that expose object interfaces for tightly bound interactions and loosely coupled interfaces in the form of commands, events, and subscriptions.
图 1‑2 WorkItem 结构＋模式
Note：
a WorkItem is a container.
1.4. Infrastructure Services
The Composite UI Application Block includes a set of basic infrastructure services that you can use in your applications. You can also build your own services that provide infrastructure capabilities specific to your applications.
1) Catalog Reader service
2) Module Loader service （模块加载）
3) Authentication service （权限认证）
4) State Persistence service （状态持久）
1.5. Modules
Modules are composed of a set of services,WorkItems,SmartParts, controllers, business entities, and the Module Initialization class, which is used for initializing and running the module's WorkItems.
1.6. Module Services
Module services are objects that you can register once by using the Service attribute, and then reference from any other component from within any WorkItem.
1.7. State
1) A WorkItem contains state, which is a loosely typed collection of objects shared by the components collaborating in the use case. State can be persisted by calling the Load and Save methods on WorkItem.
2) State can be persisted to any storage medium by using an infrastructure service that implements IStatePersistenceService. There are two built in implementations of this service: FileStatePersistenceService, which will persist the WorkItem to a file in the same directory as the executable and IsolatedStorageStatePersistenceService, which will persist the WorkItem to a file in Isolated Storage.
1.8. Controllers
The controllers have the same role that they have in the MVC pattern. They are there to implement the business logic behind the view.
Extension：
The Controller base class provides the functionality to access the WorkItem that instantiates the SmartPart and this controller. The Controller base class also provides access to the current state associated with the WorkItem.
1.9. Service Agents
Service agents are components that are used to interact with any external back-end services.
1.10. EventBroker
Components that need to publish or receive notifications use events to perform these tasks. The Composite UI Application Block (CAB) contains the EventBroker feature, which helps you to implement a multicast event scheme (that is, a scheme where zero or more event publications work with zero or more event subscriptions).
2. dependency assemblies依赖组件
The assemblies that you use in a typical CAB implementation are:
1) Microsoft.Practices.CompositeUI.WinForms.dll
2) Microsoft.Practices.CompositeUI.dll
3) Microsoft.Practices.ObjectBuilder.dll
3. Hard Code
3.1. ModuleInit
The class in a module assembly that inherits from ModuleInit is constructed when the CAB is initialized, and its Load method is executed accordingly. It is a mechanism used to initialize a module and all of its segments.
If you want to programmatically add services to the module, override the AddServices method of the ModuleInit class.
If you want to display the user interface or perform custom logic on startup, override the
Load method of the ModuleInit class. These methods are not mandatory.
3.2. ProfileCatalog.xml
The Composite UI Application Block supports the customization of an application by using solution profiles in a catalog. A solution profile is a list of modules that should be loaded into an application.
Because you have created a module and you want to use it in your application, you must define it in the ProfileCatalog.xml. This allows the module loader to load the module.
Example：
<?xml version="1.0" encoding="utf-8" ?>
<SolutionProfile xmlns="http://schemas.microsoft.com/pag/cab-profile" >
<Modules>
<ModuleInfo AssemblyFile="GPSModule.dll"/>
</Modules>
</SolutionProfile>
3.3. Creating the Program and Root WorkItem
[STAThread]
static void
{
new Program().Run();
}
Call the Run method on the class. The class implements FormShellApplication<WorkItem, MainForm> and you pass it the type of work item to use and the form to use as the shell.
Calling Run will load the ProfileCatalog.xml file and determine which modules it needs to load. After it retrieves the list of modules, it will begin loading them and initializing them. If any of the modules contain a ModuleInit class, it will construct the class and call the appropriate Load and/or AddServices methods.
4. practice
4.1. WorkItems
A WorkItem is a unit of work that helps to complete a use case. In most cases, there are five components which compose a WorkItem. These are the visual aspect, the business logic controller, the business entities (customer, account, and so on), services, and state.
During its lifetime, a WorkItem drives the use case by showing or hiding appropriate views. A WorkItem can be composed of other nested WorkItems, each of which can have its own state. This state is analogous to ASP.NET session state.
You can use special persistence techniques to save WorkItems and then restore them later.
Extension：
There are a number of ways to communicate information between WorkItems and their peer components. One way to achieve this is to store a common state between the WorkItem and its views.
The WorkItem base class holds a property named State that allows you to store a key and value pair. WorkItems have a parent/child relationship; therefore, you can share state between multiple child WorkItems by exposing the state element via a public property.
When storing objects into the State collection on the WorkItem, every one of its views that places the [State] attribute upon a public property will have the object state injected into it at runtime. You can provide a key with the attribute to specify which item in the state will be injected, or if you omit the key, the first object matching the type will be used. This means that we can effectively use the state across all our views without needing to expose a public property within the parent work item.
Example：
[State]
public Customer Customer
{
set { customer = value; }
}
4.1.1. Basic WorkItem
4.1.2. Nested WorkItems
5. Attribute
5.1. Service attribute
Service attribute above a class. This attribute is used to register the class as service for the current module. That way, the CAB can easily retrieve the implementations of the services and use them where necessary. You are establishing the ServiceType as the type of your IGPSService interface, which allows you to easily change the implementation without affecting any other code that may need to refer to this service.
Example：
public interface IGPSService
{
int GetLatitude();
int GetLongitude();
}
[Service(typeof(IGPSService))]
public class GPSService : IGPSService
{
public int GetLatitude()
{
return 42;
}
public int GetLongitude()
{
return 125;
}
}
The second service introduces a feature called On Demand Services. You use On Demand Services to specify that a service will not be instantiated until it is actually requested for use. To use On Demand Services, add the AddOnDemand attribute, and set it to true.
Example：
public interface IDistanceCalculatorService
{
int ComputeDistance(int latitude, int longitude);
}
[Service(typeof(IDistanceCalculatorService), AddOnDemand = true)]
public class DistanceCalculatorService : IDistanceCalculatorService
{
public DistanceCalculatorService()
{
MessageBox.Show("This is DistanceCalculatorService being constructed for the first time. Subsequent calls to the service will not require construction.", "Service constructed", MessageBoxButtons.OK, MessageBoxIcon.Information);
}
public int ComputeDistance(int latitude, int longitude)
{
return 1234;
}
}
5.2. ServiceDependency attribute
private IGPSService gpsService;
[ServiceDependency]
public IGPSService GPS
{
set { gpsService = value; }
}
This code tells the CAB that this class has a dependency on the IGPSService. You have not initialized a new service. You want to use the service that has already been created and stored.
The CAB uses Inversion of Control (IOC) or Dependency Injection to accomplish this task. When you place the [ServiceDependency] attribute on the member property, it will automatically initialize it with the correct service at run time when the view is added to the WorkItem.
5.3. SmartParts attribute
[SmartPart]
public partial class CustomerQueueView : UserControl
This attribute marks the control as a SmartPart. This is required to support the inversion of control functionality, which will automatically associate service dependencies, controllers, and so on.
5.4. InjectionConstructor
[InjectionConstructor]
public BankTellerModuleInit([ServiceDependency] WorkItem workItem)
{
this.workItem = workItem;
}
5.5. CommandHandler
5.6. EventPublication
Example：
[EventPublication("topic://BankShell/statusupdate", PublicationScope.Global)]
public event EventHandler<DataEventArgs<string>> UpdateStatusTextEvent;
protected virtual void OnStatusTextUpdate(string newText)
{
if (UpdateStatusTextEvent != null)
{
UpdateStatusTextEvent(this, new DataEventArgs<string>(newText));
}
}
1) Notes:
This attribute uses two parameters: the event topic and the PublicationScope. The event topic is a string that identifies the event, for example "topic://BankShell/statusupdate". It is recommended that you use a URI syntax to allow for hierarchical naming conventions. For example, topic://UpdatesAvailable/New and topic://UpdatesAvailable/Deleted. The PublicationScope specifies what components will be able to receive the event.
2) PublicationScope settings are: