Modules are distinct deployment units of a Composite UI Application Block application. Typically, they include some combination of services, WorkItems, SmartParts, controllers, presenters, and business entities. With modules, you can encapsulate a set of concerns of your application and deploy them to different users or applications.
Loading Modules
The Composite UI Application Block provides a service to load modules when the application starts. By default, it uses an XML catalog file to determine the modules to load. The default name for this file is ProfileCatalog.xml.
When the Composite UI Application Block loads a module, it uses reflection to determine whether the module includes a class that implements the IModule interface.
Module Dependencies
You can create modules that are independent of one another. You can also create modules that are used by other modules.
When one module has a dependency on another module, you express the dependency with the ModuleDependency attribute.
[assembly: ModuleDependency("BranchSystems.Module")]
Composite UI Application Block will load modules with dependencies after the modules on which they are dependent.
Wiring the Parts Together with the Injection System
To support component independence, a component must be able to use another component without requiring a change to the source code of the component to be used. To support this, the Composite UI Application Block uses dependency injection to create component object instances.
Composite UI Application Block application contains attributes such as CreateNew and ServiceDependency. These attributes support the injection of objects at run time. ObjectBuilder uses the factory pattern to create object instances. It supports a general-purpose attribute-based dependency injection.
Instead of directly constructing an object instance, you use the AddNew method of Composite UI Application Block container classes. The following code executes, ObjectBuilder creates an instance of the OfficerView class.
WorkItem.SmartParts.AddNew(); Creating New Objects
An object in your application requires an instance of another object.
The CustomerWorkItemController class uses the Composite UI Application Block to create an instance of the OfficerView class in its Run method.
private IOfficerView _officerView = null;
public void Run(QueueEntry queueEntry, IWorkspace workspace)
{ …
_officerView = WorkItem.SmartParts.AddNew();
…
}
The OfficerView class requires an instance of the OfficerViewPresenter class but does not contain code to instantiate an instance. Instead, the OfficerView class uses the CreateNew attribute.
Registering a ConstructorA class can contain more than one constructor. ObjectBuilder first looks for any constructor decorated with the [InjectionConstructor] attribute (there can be only one of these) and uses this constructor if found.
Locating a Service[InjectionConstructor]
public OfficerPanelViewPresenter(…)
{
…
}
You can add the ServiceDependency attribute to a property in your class to obtain a reference to a service declaratively. The property specifies the type of service or interface you require.
Frequently, the ServiceDependency attribute is used for the arguments in a constructor. This means that ObjectBuilder will instantiate the required services when it creates the dependent objectprivate IMyService service;
[ServiceDependency]
public IMyService MyService
{
set { service = value; }
}
