When to Use This Guidance

This topic describes some of the problems you might encounter when building enterprise WPF (Windows Presentation Foundation) client applications or Silverlight Rich Internet Applications (RIAs), how the Composite Application Guidance helps you to address those problems, and how the Composite Application Guidance compares to alternative approaches.

Application Development Challenges

Typically, developers of client applications face a number of challenges. Application requirements can change over time. New business opportunities and challenges may present themselves, new technologies may become available, or even ongoing customer feedback during the development cycle may significantly affect the requirements of the application. Therefore, it is important to build the application so that it is flexible and can be easily modified or extended over time. Designing for such flexibility can be hard to accomplish. It requires an architecture that allows individual parts of the application to be independently developed and tested and that can be modified or updated later, in isolation, without affecting the rest of the application.

Most enterprise applications are sufficiently complex that they require more than one developer, maybe even a large team of developers that includes user interface (UI) designers and localizers in addition to developers. It can be a significant challenge to decide how to design the application so that multiple developers or sub-teams can work effectively on different pieces of the application independently, yet ensuring that the pieces come together seamlessly when integrated into the application.

Designing and building applications in a monolithic style can lead to an application that is very difficult and inefficient to maintain. In this case, "monolithic" refers to an application in which the components are very tightly coupled and there is no clear separation between them. Typically, applications designed and built this way suffer from a number of problems that make the developer's life hard. It is difficult to add new features to the system or replace existing features, it is difficult to resolve bugs without breaking other portions of the system, and it is difficult to test and deploy. Also, it impacts the ability of developers and designers to work efficiently together.

The Composite Approach

An effective remedy for these challenges is to partition the application into a number of discrete, loosely coupled, semi-independent components that can then be easily integrated together into an application "shell" to form a coherent solution. Applications designed and built this way are named composite applications.

Composite applications provide many benefits, including the following:

• They allow modules to be individually developed, tested, and deployed by different individuals or sub-teams; they also allow them to be modified or extended with new functionality more easily, thereby allowing the application to be more easily extended and maintained. Note that even single-person projects experience benefits in creating more testable and maintainable applications using the composite approach.
• They provide a common shell composed of UI components contributed from various modules that interact in a loosely coupled way. This reduces the contention that arises from multiple developers adding new functionality to the UI, and it promotes a common appearance.
• They promote re-use and a clean separation of concerns between the application's horizontal capabilities, such as logging and authentication, and the vertical capabilities, such as business functionality that is specific to your application.
• They help maintain a separation of roles by allowing different individuals or sub-teams to focus on a specific task or piece of functionality according to their focus or expertise. In particular, it provides a cleaner separation between the user interface and the business logic of the application—this means the UI designer can focus on creating a richer user experience.

Composite applications are highly suited to a range of client application scenarios. For example, a composite application is ideal for creating a rich end-user experience over a number of disparate back-end systems. Figure 1 shows an example of this type of a composite application.

Figure 1

Composite application with multiple back-end systems

In this type of application, the user can be presented with a rich and flexible user experience that provides a task-oriented focus over functionality that spans multiple back-end systems, services, and data stores, where each is represented by one or more dedicated modules. The clean separation between the application logic and the user interface allows the application to provide a consistent and differentiated appearance across all constituent modules.

Additionally, a composite application can be useful when there are independently evolving components in the UI that heavily integrate with each other and that are often maintained by separate teams. Figure 2 shows a screen shot of this type of application. Each of the areas highlighted represent independent components that are composed into the UI.

Figure 2

Stock Trader Reference Implementation composite application

In this case, the composite allows the application's user interface to be dynamic composed. This delivers a flexible user experience. For example, it can allow new functionality to be dynamically added to the application at run time, which enables rich end-user customization and extensibility.

Concerns Not Addressed by the Composite Application Guidance

Please note that the Composite Application Guidance does not directly address the following:

• Occasional connectivity
• Messaging infrastructure, including the following:
  • Client/server communication
  • Asynchronous communication
  • Encryption
• Application performance
• Authentication and authorization
• Handling thread-safety from background updates, including the following:
  • Data races
  • Data synchronization
  • Handling UI updates from multiple threads (the Composite Application Library addresses some aspects of this)
• Versioning
• Error handling and fault tolerance

For more information about these topics, see the following resources on MSDN:

• Smart Client Architecture and Design Guide
• Occasionally Connected Systems Architecture: The Client
• Occasionally Connected Systems Architecture: Concurrency

Guidelines for Choosing Composite UI Guidance Assets from patterns & practices

The patterns & practices team has several guidance assets for building composite applications. The following list highlights the scenarios where you should consider using each:

• If you want to create a composite application with WPF or Silverlight or upgrade an existing WPF or Silverlight application to a composite application, use this guidance:

  • It targets WPF and Silverlight composite application development.

  • It is designed to take advantage of WPF and Silverlight capabilities.

  • It includes a lightweight library—you can choose the library capabilities you want to include.

  • It integrates with existing applications and libraries.

    Note

    The Composite Application Guidance for WPF and Silverlight does not include guidance automation.

• If you need to develop a composite Windows Forms application, consider using the Smart Client Software Factory:

  • It offers a good development and debugging experience (including tooling, control support, drag and drop, and rapid application development experience).
  • It includes code generation (this is provided with guidance package support and recipes).
  • It includes capabilities for occasionally connected clients.

• If you need to develop a composite Windows Forms host application with Windows Presentation Foundation (WPF) content, consider using Smart Client Software Factory and WPF interop:

  • It can be leveraged with an existing Smart Client Software Factory infrastructure.
  • It includes guidance automation (in the form of guidance package support and recipes).

• If you want to migrate an existing Composite UI Application Block application to WPF, consider using WPFCAB in the SCSFContrib CodePlex project:

  • It allows building pure WPF-based applications with the Composite UI Application Block.

  • It can be leveraged with an existing Smart Client Software Factory infrastructure, except for views.

    Note

    The WPFCAB is not maintained or owned by the patterns & practices team; instead, it is supported by the community. It is a literal port of Composite UI Application Block to WPF and is not optimized to take advantage of WPF. It does not include guidance automation.

Comparing to the Composite UI Application Block

This is not a new version of the patterns & practices Composite UI Application Block (sometimes referred to as CAB) originally released in 2005. It is a new set of libraries and guidance, built from the ground up that is designed to help you develop new WPF or Silverlight composite applications. Although it is not a new version of the application block, it uses the same core concepts, such as modularity, user interface (UI) composition, services, dependency injection, and event brokering. These concepts are essential for building composite applications and the Composite Application Guidance uses them; however, the implementation differs from the application block in several ways. For more information about the differences between the Composite UI Application Block and the Composite Application Guidance for WPF and Silverlight, and for guidance on how to upgrade, see Upgrading from the Composite UI Application Block.

More Information

For a recommended approach to evaluating the Composite Application Guidance, see Evaluating the Composite Application Guidance.

Home page on MSDN | Community site