设计富客户端应用

翻译自：https://msdn.microsoft.com/zh-cn/library/ee658087.aspx#中国 (简体中文)

有适当删减。没翻译完，本文大致描述了富客户端应用架构的问题与对策，值得一看。

目录

• 概述
• 常规设计考虑
• 特定设计问题
• 安全考虑
• 数据处理考虑
• 离线／临时连接 考虑
• 技术考虑
• 部署考虑
• 相关的设计模式
• 其他资源

概述

富客户端 UIs 可以提供高性能，可交互，和丰富的用户体验，应用需要处理独立，连接，临时连接，断线等场景。

图 1 展示了一个典型的富客户端架构，指定了每层的常见的组件。

图 1  Overall view of typical rich client architecture

典型的富客户端被分解为三层：展示层，业务层 和 数据层。展示层包含UI和展现逻辑组件；业务层包含业务逻辑，业务流程和业务实体组件；数据层包含数据获取，服务代理组件。

常规设计考虑

当设计富客户端应用，软件架构的目标是，选择恰当的技术、做结构设计以简化复杂度，比如分离任务到不同的关注领域。设计应该从性能、安全、重用、易于维护的角度，来满足应用的需求。

考虑下面设计问题：

• 基于应用需求，选择恰当的技术。Suitable technologies include Windows Forms, WPF, XAML Browser Applications (XBAP), and OBA.
• 分离展示逻辑与接口实现。Consider design patterns such as Presentation Model and Supervising Presenter (or Supervising Controller) that separate UI rendering from UI logic; which eases maintenance, promotes reusability, and improves testability. The use of separate components within the application can reduce dependencies, make maintenance and testing easier, and promote reusability.
• 分辨出展示任务和展示流程。This will help you to design each screen and each step in a multi screen or Wizard process.
• 设计出合适的、可用的接口。Take into account features such as layout, navigation, choice of controls, and localization to maximize accessibility and usability.
• 层间关注点分离。For example, extract business rules and other tasks not related to presentation and locate these in a separate business layer. Separate data access code into separate components located in a data layer.
• 重用通用展示逻辑。Libraries that contain templates, generalized client-side validation functions, and helper classes may be reusable in several applications.
• 保证客户端与远端服务低耦合。Use a message-based interface to communicate with services located on separate physical tiers.
• 避免与不同层的对象紧耦合。Use the abstraction provided by common interface definitions, abstract base classes, or messaging when communicating with other layers of the application. For example, implementing the Dependency Injection and Inversion of Control patterns can provide a shared abstraction between layers.
• 访问远端层的时候，减少环形依赖（round trips）Use coarse-grained methods and execute them asynchronously if possible to avoid blocking or freezing the UI.

特定设计问题

• 业务层
• 通信
• 组合（Composition）
• 配置管理
• 数据访问
• 异常管理
• 可维护性
• 展示层
• 状态管理
• 工作流

业务层（应用内）

• 识别应用所需的业务层和服务接口。If the application will access remote services, import the interface definitions and write code that accesses these service functions using the interfaces. This helps to minimize coupling between the client and a remote business layer or services that it uses.
• 如果业务逻辑不包含敏感信息，考虑将业务规则放在客户端，从而改进UI以至于app的表现。If your business logic does contain sensitive information, you should locate the business layer on a separate tier.
• 考虑客户端如何获取以下信息：业务操作规则，其他客户端处理，自动更新变化，用户或管理员更新业务规则。 You may decide to have the client obtain business rule information from a remote server when it starts up.

For more information about designing the business layer, see Chapter 7 "Business Layer Guidelines."

通信

如果富客户端应用的业务、数据层，被放置在远端，暴露为服务；它可以用多种多样的协议和方法，与这些服务通信。可能包括 HTTP requests, Simple SMTP e-mail messages, SOAP Web service messages, DCOM for remote components, remote database access protocols, or other TCP/IP-based standard or custom communication protocols. 如果业务、数据层放置在客户端，展示层可以使用基于对象的方法与之交互。在设计通信策略的时候，考虑以下指导：

• 当与物理远端的服务通信，尽可能使用基于消息的协议。This gives you a more natural way to make asynchronous calls to avoid blocking the presentation layer, and to support load balanced and failover server configurations. Use coarse-grained interfaces to minimize network traffic and maximize performance.
• 如果需要，让应用支持离线处理。Detect and monitor the connection state. When disconnected, cache information locally and then resynchronize when communication is re-enabled. Consider holding application state and data locally in a persistent cache to allow disconnected start up and a shutdown/restart cycles without information loss.
• 为了保护敏感信息和通信频道，考虑使用 IPSec 和 SSL 去保护信道，通过加密来保护数据，通过数字签名来检测数据篡改（data tampering）。
• 如果应用必需要消费、发送大量数据，考虑潜在性能、网络影响。Choose more efficient communication protocols such as TCP, using compression mechanisms to minimize the data payload size for message-based protocols such as SMTP and SOAP, or custom binary formats when the application does not need to support open communication standards.

组合（Composition）

要最大化应用的可扩展性和可维护性，particularly where it exposes a complex UI as is common in many business scenarios—考虑用设计模式组合实现可接口，在UI包含了分离的模块或者在运行时动态加载的表单。在用户可能打开多个表单来完成特定的任务，和用多种方式处理数据时，这样的方法很有用。用户可以按需打开和关闭表单，应用可以用懒加载（对应于预加载），来最大化表现和减少启动延迟。同时又考虑到你如何为用户支持个性化，然后他们可以按自己的需求修改布局、内容。由此可以参考下面的指导：

• 基于功能性说明和需求，确定你所需要的恰当的组件接口类型。For example, possible components include Windows Forms, WPF forms, Office-style documents, user controls, or custom modules.
• 考虑到从可重用模块部分组合视图，在恰当的地方，确定一个恰当的组合机制。For example, use the Composite View pattern to build a view from modular, atomic component parts. You may alternatively decide to use a composition framework such as the patterns & practices Composite Client Application Guidance, or built-in features of your development environment such as user controls or document panels. However, be careful with dependencies between components, and use abstraction patterns when possible to avoid issues with maintainability. Implement, where possible, features for managing auto update and versioning of composable components.
• 如果你必需要支持不同的表单和（构成了组合接口的）展示组件间通信，考虑实现解耦通信技术，比如：发布订阅，命令模式。This will minimize the coupling between these components and improve testability.
• 利用模板、数据绑定技术的优点，去选择实现层面的技术，以至于简化、最少化，使用了可组合接口的每个表单的代码。
• 考虑到实现个性化，那么用户可以自定制可组合组件的布局。

配置管理

富客户端应用通常需要在启动、运行期间，需要配置信息。这些信息可能是网络、连接、连接信息、用户设置、UI 业务规则 或者 常规显示和布局设置。你要决定存储一些或所有信息在本地，或者在启动时从远端下载下来。你又或许需要在应用运行、结束时，持久化信息变更，比如：存储用户喜好，布局配置，其他UI数据。

• 决定应用生命周期里，哪些配置数据会变化，for example, file locations, developer versus production settings, logging, assembly references, and contact information for notifications. If necessary, design the application to detect and dynamically apply the configuration changes.
• 选择本地或中心化存储地方。User managed data (including profile information or personalization settings) should generally be stored locally, though you may consider storing it centrally to enable roaming. Global application settings should be stored in a central location, and perhaps downloaded locally for performance reasons.
• 识别出敏感配置信息，实现合理的机制来保证网络传输的安全性。when persisted locally, and even when stored in memory.
• Take into account any global security policies and Group Policy overrides that might affect or override local configurations.

数据访问

Rich client applications will usually access data stored on a remote server, as well as data stored on the local machine. Data access often has a significant impact on performance, and is the most obvious factor in the user's perception of an application and its usability and responsiveness. You should aim to maximize performance of data access routines and data transmission across tiers. You must also design the application with regard to the types of data it will use. If the client application cannot handle the data in the exposed format, you must implement a translation mechanism that converts it. However, this will have an impact on performance. Consider the following guidelines when designing a data access strategy:

• Whenever possible, load data asynchronously so that the UI is still responsive while the data is loading. However, you must also be aware of conflicts that might occur if the user attempts to interact with the data before loading is complete, and design the interface to protect against errors arising from this.
• If the client will consume very large amounts of data, consider chunking these and loading them asynchronously into a local cache to improve performance. You must plan how you will handle inconsistencies between the local copy and the original data, perhaps by using methods such as time stamps or events.
• In occasionally connected scenarios, monitor connectivity and implement a service dispatcher mechanism to support batch processing so that users can perform multiple updates to data.
• Determine how you will detect and manage concurrency conflicts that arise when multiple users attempt to update the central data store. Explore optimistic and pessimistic concurrency models.

For more information about data access and handling data in rich client applications, see "Data Handling Considerations" later in this chapter.

异常管理

All applications and services are subject to the occurrence of errors and exceptions, and you must implement a suitable strategy for detecting and managing these errors and exceptions. A robust and well designed exception management strategy can simplify application design, and improve security and manageability. It can also make it easier for developers to create the application, and reduces development time and cost. In a rich client application, you will usually need to notify the user. In addition, for anything other than trivial UI errors such as validation messages, you should consider logging errors and exceptions for use by operations staff and monitoring systems. The main challenge here is usually collating log information or designing a centralized server-based logging sink that can be accessed by all clients. Consider the following guidelines when designing an exception management strategy:

• Identify the errors and exceptions that are likely to arise within the application, and identify which of these require only user notification. Errors such as validation failures are usually only notified locally to the user. However, errors such as repeated invalid logon attempts or detection of malicious data should be logged and administrators notified. All execution exceptions and application failures should be logged and, optionally, administrators notified.
• Identify an overall strategy for handling exceptions. This may involve actions such as wrapping exceptions with other application specific or custom exceptions that contain additional data to assist in resolving failures, or replacing exceptions to prevent exposure of sensitive information. Also, implement a mechanism for detecting and logging unhandled exceptions. A framework for managing exceptions, such as the patterns & practices Enterprise Library, may be useful for these tasks.
• Determine how you will store exception information, how you will pass it to other layers of the application if required, and how you will notify administrators. Consider using a monitoring tool or environment that can read events from the local machine and present a view of the application state to administrators.
• Ensure that you sanitize exception information that is exposed to users in order to prevent sensitive information from being displayed or stored in log and audit files. If necessary, encrypt information and use secure channels to communicate exceptions and errors to other physical tiers of the application.
• Only catch exceptions that you can handle. For example, catch data conversion exceptions that can occur when trying to convert null values. Do not use exceptions to control business logic.

可维护性

It is vital to minimize maintenance cost and effort for all applications and components. You should implement mechanisms that reduce maintenance liabilities; for example, by using design patterns that provide good separation of concerns and loose coupling between components. Rich client applications are usually located on remote client machines, and are subsequently more difficult to operate than server installed applications. Other issues to consider, therefore, include deployment, updates, patches, and versioning. Consider the following guidelines when designing a maintainability strategy:

• Implement a suitable mechanism for manual and/or automatic updates to the application and its components. You must take into account versioning issues to ensure that the application has consistent and interoperable versions of all the components it uses.
• Choose an appropriate deployment approach based on the environment in which your application will be used. For example, you might require an installation program for applications that are publically available, or you may be able to use system tools such as Microsoft System Center to deploy applications within a closed environment.
• Design the application so that components are loosely coupled and interchangeable where possible. This allows you to change individual components depending on requirements, run-time scenarios, and individual user requirements or preferences. Also, design to minimize dependencies between components and layers so that the application or the individual layers and components can be used in different scenarios where appropriate.
• Implement logging and auditing as appropriate for the application to assist administrators and developers when debugging the application and solving run-time problems.

For more information about maintainability, see Chapter 16 "Quality Attributes."

展示层

The presentation layer is the part of the application that the user sees and interacts with, and it must therefore satisfy many requirements. These requirements encompass general factors such as usability, performance, design, and interactivity. A poor user experience can result in a severely negative impact on an application that performs well in all other respects. It is important to design your application to support a compelling and intuitive user experience from the outset, as the user experience is influenced by many different aspects of your application's architecture. Consider the following guidelines when designing the presentation features of your application:

• Investigate how you can separate the logic for managing user interaction from the UI, and from the data with which the user works—perhaps by applying a Separated Presentation style. This makes it easier to update parts of the application, allows developers and designers to work separately on the components, and improves testability.
• Implement command and navigation strategies and mechanisms that are flexible and can be updated easily. Consider implementing well-known design patterns such as Command, Publish/Subscribe, and Observer to decouple commands and navigation from the components in the application and to improve testability.
• Take advantage of data binding capabilities to display data whenever possible, especially for tabular and multirow data presentation. This reduces the code required, simplifies development, and reduces coding errors. It can also automatically synchronize data in different views or forms. Use two-way binding where the user must be able to update the data.
• Consider how you will display documents in an Office document—style interface, or when displaying document content or HTML in other UI elements. Ensure that the user is protected from invalid and malicious content that might reside in documents.
• Ensure that the application UI can be internationalized and then localized to all geographical and cultural scenarios where it may be used. This includes changing the language, text direction, and content layout based on configuration or auto detection of the user's culture. Also, ensure that you provide appropriate support for accessibility and navigation.

For more information about presentation layer design considerations, see Chapter 6 "Presentation Layer Guidelines."

状态管理

State management concerns the persistence of data that represents the state of a component, operation, or step in a process. State data may include user settings, configuration information, workflow information, business rule values, and data that the UI displays. The application must be able to save this data, access it as required, and handle conflicts, restarts, and connection status changes. Consider the following guidelines when designing a state-management strategy:

• Determine the state information that the application must store, including estimates of the size, the frequency of changes, and the processing or overhead cost of re-creating or refetching the data; and ensure that your chosen state management mechanism can provide appropriate support.
• If you have large volumes of state data, consider using a local disk-based mechanism to store it. If the application requires data to be available when it starts up, use a persistent mechanism such as isolated storage or a disk file.
• When storing sensitive data, ensure that you implement the appropriate level of protection by using encryption and/or digital signatures.
• Consider at what granularity you must maintain state information. For example, determine the state information that applies to all users of an application and the information that applies only to specific users or roles.

工作流

Some rich client applications require view flow or workflow support to enable multistep operations or Wizard-style UI elements. You can implement these features using separate components or custom solutions, or you can take advantage of a framework such as Windows Workflow Foundation (WF). Consider the following guidelines when designing a workflow strategy:

• Use workflow within business components for operations that involve multistep or long-running processes. Consider creating separate components to implement your workflow and view flow tasks. This reduces dependencies and makes it easier to interchange components as requirements change.
• For simple workflow and view flow requirements, it is usually sufficient to use custom code based on well-known patterns such as Use Case Controller and ViewFlow. For workflow and view flow requirements that are more complex, consider using a workflow engine such as WF.
• Consider how you will capture, manage, and display errors in workflows. Also, identify how you will handle partially completed tasks, and whether it is possible to recover from a failure and continue the task or whether you must restart the process.

For more information about workflow components, see Chapter 14 "Designing Workflow Components."

安全考虑

Security encompasses a range of factors and is vital in all types of applications. Rich client applications must be designed and implemented with security in mind, and—where they act as the presentation layer for business applications—must play their part in protecting and securing the other layers of the application. Security issues involve a range of concerns, including protecting sensitive data, user authentication and authorization, guarding against attack from malicious code and users, and auditing and logging events and user activity. Consider the following guidelines when designing a security strategy:

• Determine the appropriate technology and approach for authenticating users, including support for multiple users of the same rich client application instance. You should consider how and when to log on users, whether you must support different types of users (different roles) with differing permissions (such as administrators and standard users), and how you will record successful and failed logons. Take into account the requirements for disconnected or offline authentication where this is relevant.
• Consider using Windows Integrated Authentication or a federated authentication solution if users must be able to access multiple applications with the same credentials or identity. If you cannot use Windows Integrated Authentication, you may be able to use an external agency that offers federated authentication support. If you cannot use an external agency, consider using a certificate-based system, or create a custom solution for your organization.
• Consider the requirement to validate inputs, both from the user and from sources such as services and other application interfaces. You might need to create custom validation mechanisms, or you might be able to take advantage of the validation features of the technology you are working with. The Microsoft Visual Studio® Windows Forms development environment contains validation controls. Alternatively, consider a third party validation framework such as the Enterprise Library Validation Application Block, which provides comprehensive features for validation in the UI and in the business layer. Irrespective of your validation choice, remember that you must always validate data when it crosses trust boundaries.
• Consider how you will protect data stored in the application and in resources such as files, caches, and documents used by the application. Encrypt sensitive data where it might be exposed, and consider using a digital signature to prevent tampering. In maximum security applications, consider encrypting volatile information stored in memory. Also, remember to protect sensitive information that is sent from the application over a network or communication channel.
• Consider how you will implement auditing and logging for the application, and what information to include in these logs. Remember to protect sensitive information in the logs using encryption, and optionally use digital signatures for the most sensitive information that is vulnerable to tampering.

数据处理考虑

Application data can be made available from server-side applications through a Web service. Cache this data on client to improve performance and enable offline usage. Rich client applications can also use local data. Data use by rich client applications falls into two categories:

• Read-only reference data. This is data that does not change often and is used by the client for reference purposes, such as a product catalog. Store reference data on the client to reduce the amount of data interchange between the client and the server in order to improve the performance of your application, enable offline capabilities, provide early data validation, and generally improve the usability of your application.
• Transient data. This is data that can be changed on the client as well as on the server. One of the most challenging aspects of dealing with transient data in rich client applications is dealing with concurrency issues where the same data can be modified by multiple clients at the same time. You must keep track of any client-side changes made to transient data on the client and manage updates on the server that may contain conflicting changes.

缓存数据

Rich clients often must cache data locally, whether it is read-only reference data or transient data. Caching data can improve performance in your application and provide the data necessary to work offline. To enable data caching, rich client applications should implement some form of caching infrastructure that can handle the data caching details transparently. The common types of caching are:

• Short term data caching. Data is not persistent, so the application cannot run offline.
• Long term data caching. Caching data in a persistent medium, such as isolated storage or the local file system, allows the application to work when there is no connectivity to the server. Rich client applications should differentiate between data that has been successfully synchronized with the server and data that is still tentative.

数据并发

When serving multiple clients simultaneously, changes to the data held on the server can occur before a specific client's changes can be synchronized with the server. This can lead to data corruption or inconsistencies. You must, therefore, implement a mechanism to ensure that any data conflicts are handled appropriately when the data is synchronized, and that the resulting data is consistent and correct. Common approaches for handling data concurrency are:

• Pessimistic concurrency. Pessimistic concurrency assumes that the risk of a data conflicts is high. To prevent data conflicts, it allows one client to maintain a lock over the data, thereby preventing any other clients from accessing or modifying the data until the client's own changes are completed and committed. This pattern is also known as the pessimistic offline lock pattern.
• Optimistic concurrency. Optimistic concurrency assumes that the risk of data conflicts is low. With optimistic concurrency, the data is not locked by a client while it is being updated. To detect data conflicts, the original data and the changed data are both sent to the server. The original data is checked against the current data to see if it has been updated since it was last retrieved. If not, the changes are applied; otherwise a data conflict exception is raised. This pattern is also known as the optimistic offline lock pattern.

The ADO.NET DataSet helps clients to work with data while offline. DataSets can keep track of local changes made to the data, which makes it easier to synchronize the data with the server and reconcile data conflicts. DataSets can also be used to merge data from different sources.

数据绑定

Windows Forms, WPF, and Silverlight data binding supports bidirectional binding that allows you to bind a data structure to a UI component, display the current data values to the user, allow the user to edit the data, and then automatically update the underlying data using the values entered by the user. Data binding can be used to display read-only data to users, allow users to update data within the UI, provide master\detail views of data, allow users to explore complex related data items, and provide lookup table functionality that allows the UI to display user friendly names for data items instead of data row key values.

离线／临时连接

An application is occasionally connected if, during unspecified periods, it cannot interact with services or data over a network in a timely manner. Occasionally connected rich client applications are capable of performing work when not connected to a networked resource, and can update the networked resources in the background when a connection is available.

When designing occasionally connected applications, aim to favor asynchronous communication when interacting with data and services over a network and minimize or eliminate complex interactions with network located data and services. This makes it easier to implement a synchronization mechanism for use when a connection is available.

In order to work when disconnected, your application should implement data caching capabilities that provide all of the data necessary on the client for the user to continue working when offline. You must also determine how to prevent the application using stale data. In general, you should consider designing a store and forward mechanism where messages are created, stored while disconnected, and eventually forwarded to their respective destinations when a connection becomes available. The most common implementation of store and forward is a message queue.

Consider the following two approaches when designing for an occasionally connected scenario:

• 中心化数据。 Applications that use the data centric strategy have a relational database management system (RDBMS) installed locally on the client, and use the built-in capabilities of the database system to propagate local data changes back to the server, handle the synchronization process, and detect and resolve any data conflicts.
• 面向服务。 Applications that use the service-oriented approach store information in messages, and arrange these messages in queues while the client is offline. After the connection is reestablished, the queued messages are sent to the server for processing.

技术考虑

There are several different technologies available that you can use to implement a rich client application. The following guidelines will help you to choose an appropriate implementation technology, and provide guidance on the use of appropriate patterns and system functions for configuration and monitoring:

• Choose a suitable development technology:
  • Consider WFP for applications that will fully support rich media and graphics.
  • Consider using Windows Forms if you have existing Windows Forms investments, or if you are building LOB applications that do not require rich visualization and should execute with minimal hardware requirements.
  • Consider XBAP for applications that are downloaded from a Web server and then execute in the browser.
  • Consider OBA for applications that are predominantly document-based, or are used for reporting.
• Explore patterns & practices assets that can help you to design and implement the application:
  • Consider using the Smart Client Software Factory if you decide to use Windows Forms and you are designing composite interfaces.
  • Consider using the Composite Client Application Guidance if you decide to use WPF and/or Silverlight, and you wish to develop modular applications that typically feature multiple screens, rich, flexible user interaction and data visualization, and role-determined behavior.
  • Consider Enterprise Library to help you implement solutions for crosscutting concerns such as exception handling, caching, and validation.
• If you decide to use WPF:
  • Consider implementing the Presentation Model or View Model pattern to make the UI logic unit testable and to make it easier to re-skin your application.
  • WPF allows you to attach additional behaviors to existing control implementations. Use this approach instead of attempting to subclass a control.
• If you want to support remote administration and monitoring:
  • Consider implementing Group Policy overrides for your application configuration. This is required to meet Certified for Windows logo requirements.
  • Consider using technologies such as SNMP and WMI to expose exceptions and health state.

部署考虑

There are several options for the deployment of rich client applications. You might have a stand-alone application where all of the application logic, including data, is deployed on the client machine. Another option is client/server, where the application logic is deployed on the client and the data is deployed on a database tier. Finally, there are several n-tier options where one or more application servers host part of the application logic.

独立部署（Stand-alone Deployment）

Figure 2 illustrates a stand-alone deployment where all of the application logic and data is deployed on the client.

Figure 2 

Stand-alone deployment for a rich client application

Client/Server Deployment

In a client/server deployment, all of the application logic is deployed on the client and the data is deployed on a database server, as shown in Figure 3.

Figure 3 

Client/server deployment for a rich client application

N-Tier Deployment

In an n-tier deployment, you can place presentation and business logic on the client, or only the presentation logic on the client. Figure 4 illustrates the case where the presentation and business logic are deployed on the client.

Figure 4 

N-tier deployment with the business layer located on the client tier

Figure 5 illustrates the case where the business and data access logic are deployed on an application server.

Figure 5 

N-tier deployment with the business layer located on the application tier

For more information on deployment strategies, see Chapter 19 "Physical Tiers and Deployment."

部署技术

Several options exist for deploying a rich client application to a physical machine. Each has specific advantages and liabilities, and you should research the options to ensure that the one you choose is suitable for the target environments in which your application will execute. The options are the following:

• Click Once deployment. This approach requires little user interaction, provides automated updates, and requires little effort for the developer. However, it can only be used to deploy a single solution that is not part of a larger solution; it cannot deploy additional files or registry keys; it cannot interact with the user to configure the installation; and it cannot provide a branded installation.
• XCOPY deployment. If no registry settings or component registration are required, the executable can be copied directly to the client machine hard disk.
• Windows Installer (.MSI) package. This is a comprehensive setup program that can install components, resources, registry settings, and other artifacts required by the application. Users require administrator privileges to install MSI packages themselves. There are solutions available, such as Microsoft System Center Configuration Manager, for distributing applications in a corporate environment.
• XBAP package. The application is downloaded through the browser and runs in a constrained security environment on the machine. Updates can be pushed to the client automatically.

相关的设计模式

Key patterns are organized into categories such as Communication, Composition, Configuration Management, Exception Management, Presentation, State Management, and Workflow; as shown in the following table. Consider using these patterns when making design decisions for each category.

Category	Relevant patterns
Communication	Asynchronous Callback. Execute long-running tasks on a separate thread that executes in the background, and provide a function for the thread to call back into when the task is complete. Gateway. Provide access to an external system through a common abstract interface so that consumers are not required to understand the external system interface. Service Locator. Centralize distributed service object lookups, provide a centralized point of control, and act as a cache that eliminates redundant lookups. Service Agent and Proxy. Implement a component that the consuming application can use without knowing that it is not accessing the actual target component or service. The component passes calls to the remote component or service, and returns the result to the consuming application. The proxy abstracts the details of communication with other remote components, typically when using ASMX or WCF services. Service Interface. A programmatic interface that other systems can use to interact with the service.
Composition	Composite View. Combine individual views into a composite view Template View. Implement a common template view, and derive or construct views using the template view. Two-Step View. Transform the model data into a logical presentation without any specific formatting, and then convert that logical presentation into the actual formatting required. View Helper. Delegate business data processing responsibilities to helper classes.
Configuration Management	Provider. Implement a component that exposes an API that is different from the client API in order to allow any custom implementation to be seamlessly plugged in.
Exception Management	Exception Shielding. Prevent a service from exposing information about its internal implementation when an exception occurs.
Presentation	Application Controller. An object that contains all of the flow logic and is used by other Controllers that work with a Model and display the appropriate View. Model-View-Presenter. Separate request processing into three roles, with the View being responsible for handling user input, the Model responsible for application data and business logic, and the Presenter responsible for presentation logic and for coordinating the interaction between the View and the Model. Model-View-ViewModel. A variation of Model-View-Controller (MVC) that is tailored for modern UI development platforms where the View is the responsibility of a designer rather than a classic developer. Presentation Model. Separate the responsibilities for the visual display of the user interface and the presentation state and behavior into different classes named, respectively, the view and the presentation model. The view class manages the user interface controls and encapsulates any visual state or behavior that is specific to the UI. The presentation model class encapsulates presentation behavior and state and acts as a façade onto the underlying model.
State Management	Context Object. An object used to manage the current execution context.
Workflow	View Flow. Manage navigation from one view to another based on state in the application or environment, and the conditions and limitations required for correct operation of the application. Work Flow. Manage the flow of control in a complex process-oriented application in a predefined manner while allowing dynamic route modification through decision and branching structures that can modify the routing of requests.