Jagamisviis:

Patterns in the Composite Application Library

  • Artikkel
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.

Building composite applications is a complex endeavor that involves applying different patterns. This topic describes design patterns that the Composite Application Guidance for WPF (Windows Presentation Foundation) team encountered when building composite user interface (UI) applications. Figure 1 shows a typical composite application architecture using the Composite Application Library and some of the common patterns.

Ff921146.56e26058-aa45-4790-94fc-c59fd3d563e3(en-us,PandP.10).png

Figure 1
Composite application patterns

This section provides a brief overview of each listed pattern and an area in the Composite Application Guidance code to see an example of this pattern. The following patterns are described:

  • Composite User Interface patterns:
    • Composite and Composite View
    • Command
    • Adapter
  • Modularity patterns:
    • Separated Interface and Plug In
    • Service Locator
    • Event Aggregator
    • Façade
  • Testability patterns:
    • Inversion of Control
    • Separated Presentation

Composite and Composite View

At the heart of a composite application is the ability to combine individual views into a composite view. Frequently, the composing view defines a layout for the child views. For example, the shell of the application may define a navigation area and content area to host child views at run time, as shown in Figure 2.

Ff921146.8bee58f8-b6ab-4654-8200-dd3e2744a77e(en-us,PandP.10).png

Figure 2
Composition example

For more information about the Composite pattern, see Chapter 4, "Structural Patterns," in Design Patterns: Elements of Reusable Object-Oriented Software (1). The Composite View pattern is a variation of the Composite pattern.

In the Stock Trader Reference Implementation (Stock Trader RI) application, this can be seen with the use of regions in the shell. The shell defines regions that modules locate and add views to during the initialization process. For examples of defining regions, see the Shell.xaml file.

Separated Interface and Plug-In

The ability to locate and load modules at run time opens greater opportunities for parallel development, expands module deployment choices, and encourages a more loosely coupled architecture. The following patterns enable this ability:

  • Separated Interface. This pattern reduces coupling by placing the interface definition in a separate package as the implementation. The IModule definition is part of the Composite Application Library, and each module implements the IModule interface. For an example of implementing a module in the Stock Trader RI, see the file NewsModule.cs.
  • Plug-In. This pattern allows the concrete implementation of a class to be determined at run time to avoid requiring recompilation due to which concrete implementation is used or due to changes in the concrete implementation. In the Composite Application Library, this is handled through the DirectoryLookupModuleEnumerator, ConfigurationModuleEnumerator, and the ModuleLoader. For examples of plug-ins, see the files DirectoryLookupModuleEnumerator.cs, ConfigurationModuleEnumerator.cs, and ModuleLoader.cs in the Composite Application Library.

Inversion of Control

Frequently, the Inversion of Control (IoC) pattern is used to enable extensibility in a class or framework. For example, a class designed with an eventing model at certain points of execution inverts control by allowing event listeners to take action when the event is invoked.

A form of the IoC pattern, Dependency Injection (DI), is used throughout the Stock Trader RI and the Composite Application Library. During a class's construction phase, DI provides any dependent classes to the class. Because of this, the concrete implementation of the dependencies can be changed more readily as the system evolves. This better supports testability and growth of a system over time. The Stock Trader RI uses Unity, a DI container. However, the Composite Application Library itself is not tied to a specific DI container; you are free to choose whichever DI container you want, but you must provide an adapter for it to the IContainerFacade interface. To see an example of using the container in the Stock Trader RI, see the NewsModule.cs file.

For more details about IoC and DI patterns, see Inversion of Control and Dependency Injection.

Another form of IoC demonstrated in the Stock Trader RI is the Template Method pattern. In the Template Method pattern, a base class provides a recipe, or process, that calls virtual or abstract methods. Because of this, an inherited class can override appropriate methods to enable the behavior required. In the Composite Application Library, this is shown in the UnityContainerAdapter class. For more information about the Template Method pattern, see Chapter 5, "Behavioral Patterns," in Design Patterns: Elements of Reusable Object-Oriented Software (1). To see an example of using the Template pattern in the Stock Trader RI, see the file StockTraderRIBootstrapper.cs.

Service Locator

The Service Locator pattern is a form of the Inversion of Control pattern (as described earlier in this topic). It allows classes to locate specific services they are interested in without needing to know who implements the service. Frequently, this is used as an alternative to dependency injection, but there are times when a class will need to use service location instead of dependency injection, such as when it needs to resolve multiple implementers of a service. For more information about the Service Locator pattern, see Service Locator. In the Composite Application Library, this can be seen when ModuleLoader service resolves individual IModules.

For an example of using the UnityContainer to locate a service in the Stock Trader RI, see the file NewsModule.cs.

Command

The Command pattern is a design pattern in which objects are used to represent actions. A command object encapsulates an action and its parameters. This allows a decoupling of the invoker of the command and the handlers of the command.

The Composite Application Library provides a CompositeCommand that allows combining of multiple ICommand items and a DelegateCommand that allows a presenter or model to provide an ICommand that connects to local methods for execution and notification of ability to execute. To see the usage of the CompositeCommand and the DelegateCommand in the Stock Trader RI, see the files StockTraderRICommands.cs and OrderDetailsPresentationModel.cs.

For more details about the Command pattern, see Chapter 5, "Behavioral Patterns," in Design Patterns: Elements of Reusable Object-Oriented Software (1).

Adapter

The Adapter pattern, as the name implies, adapts the interface of one class to match the interface expected by another class. For more details, see Chapter 4, "Structural Patterns," in Design Patterns: Elements of Reusable Object-Oriented Software (1).In the Composite Application Library, the Adapter pattern is used to adapt regions to the Windows Presentation Foundation (WPF) ItemsControl, ContentControl, a Selector. To see the Adapters pattern applied, see the file ItemsControlRegionAdatper.cs in the Composite Application Library.

Event Aggregator

The Event Aggregator pattern channels events from multiple objects through a single object to simplify registration for clients. For more information about this pattern, see Event Aggregator on Martin Fowler's Web site. In the Composite Application Library, a variation of the Event Aggregator pattern allows multiple objects to locate and publish or subscribe to events. To see the EventAggregator and the events it manages, see the EventAggregator and the CompositeWpfEvent in the Composite Application Library.

To see the usage of the EventAggregator in the Stock Trader RI, see the file** **WatchListPresentationModel.cs.

Separated Presentation

Separated Presentation patterns are a category of patterns that focus on keeping the logic for the presentation separate from the visual representation. Primarily, this is done to allow testing of your presentation logic without the need to involve a visual representation. There are a number of specific implementations of these patterns, such as Model-View-Controller (MVC), Model-View-Presenter (MVP) variants, and Model-View-ViewModel (MVVM). For more information about MVC and MVP variants, see GUI Architectures on Martin Fowler's Web site. For more information about MVVM, see Tales from the Smart Client on MSDN. This guidance includes a description of the Supervising Controller and Presentation Model patterns. For more information, see Supervising Controller and Presentation Model.

The Composite Application Library itself is intended to be neutral with respect to choice of Separated Presentation pattern. You can be successful with any of the patterns, although considering WPF's highly binding-oriented nature, patterns that support data-binding lend themselves better to WPF applications. The Stock Trader RI demonstrates the use of the Presentation Model pattern, an MVP variant that encapsulates the presentation logic and constructs a model to which the view can bind.

To see examples of the PresentationModel in the Stock Trader RI, see the files WatchListPresentationModel.cs, WatchListView.xaml, and WatchListService.cs.

Façade

The Façade pattern simplifies a more complex interface, or set of interfaces, to ease their use or to isolate access to those interfaces. For more details, see Chapter 4, “Structural Patterns,” in Design Patterns: Elements of Reusable Object-Oriented Software. The Composite Application Library interfaces with façades for the container and the logging services to help isolate the library from changes in those services. This allows the consumer of the library to provide their own services that will work with the Composite Application Library. The IContainerFacade.cs and ILoggerFacade.cs classes define the façade interfaces the Composite Application Library expects when communicating with a container or logging service.

More Information

The following are references and links to the patterns found in the Stock Trader RI and in the Composite Application Library:

(1) Gamma, Erich, Richard Helm, Ralph Johnson, and John Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. Addison WesleyProfessional, 1995.

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.