Jaa

Extensibility Activities

  • Artikkeli
Retired Content

This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

The Composite Application Library was designed to allow significant pieces to be customized or replaced. The reliance on a container to locate and construct key components in the architecture allows developers to replace these components with ones of their own design. In the library, you can even replace the container itself if you want.

Guidelines for Extensibility

Use these guidelines when you extend the Composite Application Library. You can extend the library by adding or replacing services, modifying the source code, or adding new application capabilities.

Exposing Functionality

A library should provide a public API to expose the libraries functionality. The interface of the API should be independent of the internal implementation. Developers should not be required to understand the library design or implementation to effectively use its out-of-box functionality. Whenever possible, the API should apply to common scenarios for a specific functionality.

Extending Libraries

The Composite Application Library provides extensibility points that developers can use to tailor the library to suit their needs. For example, by using the Composite Application Library, you can replace the logging service with your own logging service.

You can extend the library without modifying its source code. To accomplish this, you should use extensibility points, such as public base classes or interfaces. Developers can extend the base classes or implement the interfaces and then add their extensions to the library.

When defining the set of extensibility points, consider the effect on usability. A large number of extensibility points can make the library complicated to use and difficult to configure.

Some developers may be interested in customizing the code, which means that they will modify the source code instead of using the extension points. To support this effort, the library design should provide the following:

  • It should follow object-oriented design principles whenever practical.
  • It should use appropriate patterns.
  • It should efficiently use resources.
  • It should adhere to security principles (for example, distrust of user input and principle of least privilege).

Recommendations for Modifying the Composite Application Library

When modifying the source code, follow these best practices:

  • Make sure you understand how the library works by reading the topic that describes its design.
  • Consider changing the library's namespace if you significantly alter the code or if you want to use your customized version of the library along with the original version.
  • Use strong naming. A strong name allows the assembly to be uniquely identified, versioned, and checked for integrity. You will need to generate your own key pair to sign your modified version of the application block. For more information, see Strong-Named Assemblies. Alternatively, you can choose to not sign your custom version. This is referred to as weak naming.

Extensibility Points in the Composite Application Library

Use the following reference list to identify the extension points, by functional area, and associated document(s) for extending the library.

Regions

The Composite Application Library provides default control adapters for enabling a control as a region. Extensions around regions may involve providing custom region adapters, custom regions, or replacing the region manager. If you have a custom or third-party WPF control that does not work with the region adapters provided, you may want to create custom region adapters that will. It is also possible to replace the default RegionManager by supplying a new IRegionManager in the container.

For more information about the regions, region adapters, and the region manager and customization, see the following:

Logging

A number of components in the Composite Application Library log information, warning messages, or error messages. To avoid a dependency on a particular logging approach, it logs these messages to the ILoggerFacade interface. A common extension is to provide a custom logger for specific applications.

For information about providing custom loggers, see How to: Provide a Custom Logger.

Modules

The Composite Application Library provides a number of choices for locating and loading modules; however, your scenario may have needs that the library does not provide, such as locating or loading modules from a database.

Module loading is separated into enumeration and loading, represented by the IModuleEnumerator and IModuleLoader interfaces. The UnityBootstrapper uses the enumerator to retrieve the module information and supplies the results to the module loader.

For more background information about module enumeration and loading, see Module technical concept.

Communication

The two main forms of communication in the Composite Application Library are commands and events. Commands are handled by the DelegateCommand and CompositeCommand classes. Although these provide solutions to common command needs in composite applications, you may want to customize these classes for other scenarios. For example, you may need an alternate strategy for aggregating execution than what CompositeCommand offers.

The EventAggregator and CompositeWpfEvent can connect publishers and subscribers in a decoupled manner. If you need to change how events are located or created, look into extending or replacing the EventAggregator. If the event dispatching strategy does not suite your needs, consider extending or replacing the CompositeWpfEvent.

To discover more about commands and eventing in the Composite Application Library, see the following technical concept topics:

Container and Bootstrapper

The Composite Application Library comes with the Unity container; however, because the container is accessed through the IContainerFacade interface, the container can be replaced. To do this, your container will need to satisfy the IContainerFacade interface. Usually, if you are replacing the container, you will also need to provide your own container-specific bootstrapper. To provide this, examine the UnityBootstrapper to ensure the container is setup and registered with the services needed for the Composite Application Library.

For more information on the container and bootstrapper, see the following topics:

Retired Content

This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.