patterns & practices: App Arch Guide 2.0 Knowledge Base

Checklist - Rich Client Application

Design Considerations

• Design patterns, such as MVC and Supervising Controller, are used to separate presentation logic from user interface implementation.
• User interface features such as layout, navigation, choice of controls, and localization are designed to maximize accessibility and usability.
• Business rules and other tasks not related to the interface are extracted to a separate business layer.
• Client is loosely coupled from remote services it uses.
• Unnecessary round trips are reduced when accessing remote layers.

Communication

• Message-based protocols are used to communicate with business layers, services, and components on a remote physical tier when possible.
• Coarse-grained interfaces are used when communicating with business layers, services, and components on a remote physical tier to minimize network traffic and maximize performance.
• Application enables offline processing by detecting the connection state, caching information locally, and then re-synchronizing when communication is re-enabled.
• Sensitive information is protected during network transfer through use of security conscious protocols and transfer methods such as IPSec, SSL, and digital signatures

Composition

• Appropriate types of interface components have been identified based on functional specifications and requirements.
• Abstraction patterns are used to avoid dependencies between components.
• Composition framework or built-in features of the development environment are used.
• Composite View pattern us used to build a view from modular, atomic parts.
• Publish/Subscribe patterns is used for communication between presentation components.

Configuration Management

• Configurable data that may change in the life of the application is identified.
• The storage location has been identified, whether it should be stored locally or retrieved from elsewhere within the application layers.
• Global application settings are designed to be stored in a central location.
• Sensitive configuration information is protected when in memory, stored locally and in transit over the network.
• The design takes into account any global security policies that may affect or override local configurations.

Data Services

• Translation is used to handle data formats that are not supported by the client application.
• Large data sets are chunked and loaded asynchronously into a local cache to improve performance.
• UI responsiveness is maximized by loading data asynchronously when possible.
• A service dispatcher mechanism is used to monitor connectivity and send batched updates when a suitable connection is available.
• Concurrency conflicts are detected and managed using either optimistic or pessimistic models.

Exception Management

• Exceptions are not used to control logic flow.
• Exceptions are caught only if they can be handled.
• Global error handler is used to catch unhandled exceptions.
• User friendly messages are displayed when an exception or error occurs in the system.
• Exception details do not reveal sensitive information.

State Management

• The caching mechanism is designed considering the state information that the application must cache including estimates of the size, the frequency of changes, and the processing or overhead cost of recreating or re-fetching the data.
• The application uses local disk-based caching mechanism for storing large volumes of data.
• Data which needs to be available at application start-up is stored using a persistent caching mechanism such as Isolated Storage or a disk file.
• Sensitive cached data is protected using encryption and digital signatures.
• Identified the granularity of the state information.

Workflow

• Workflows are used within business components that involve multi-step or long-running processes.
• Appropriate workflow style is used depending on the application scenario.
• Simple workflows and viewflows are designed using custom code based on well-known patterns such as Use Case Controller and ViewFlow.
• Complex workflows and viewflows are designed using platform provided workflow engine such as WF.
• Workflow and viewflow tasks are implemented in separate components.
• The workflow fault conditions are handled appropriately.
• The workflow design handles partially completed tasks.

Presentation Considerations

• The UI is implemented for all the user and business application requirements.
• Design patterns, such as Command, Publish/Subscribe, and Observer are used to decouple commands and navigation from the components in the application and to improve testability.
• Workflows or Viewflows are used for implementing multi-step Wizard-like interface elements.
• Data-binding capabilities are used to display data, whenever possible. Two-way binding is used where the user is able to update the data.
• The application is designed to support globalized and localization.
• The data used by the UI is separated from the UI itself to improve testability.

Business/Service Layer Considerations

• The business layer and service interfaces are identified and the business layer service functions are designed to be accessed using the interfaces.
• The business logic which does not contain sensitive information is located on the client to improve performance of the UI and the client application.
• The business layer which contains sensitive information is located on separate tier.
• The client is designed to obtain information required to operate business rules and other client-side processing, and to update business rules automatically as requirements change.

Maintainability Considerations

• A suitable mechanism for manual and/or automatic updates to the application and its components is implemented taking into account versioning issues to ensure that the application has consistent and interoperable versions of all the components it uses.
• The appropriate deployment option is chosen depending on the presentation technology used, these may include ClickOnce, Windows Installer, and XCOPY.
• Components are designed to be interchangeable where possible, allowing change to individual components depending on requirements, runtime scenarios, and individual user requirements or preferences.
• Appropriate logging and auditing mechanism is implemented for the application to assist administrators and developers when debugging the application and solving runtime problems.
• Components and layers have minimal dependencies so that the application can be used in different scenarios where appropriate, without changes to other layers affecting the client application.

Security Considerations

• Appropriate authentication strategy is designed for disconnected or offline authentication where this is relevant.
• Appropriate authorization strategy is designed and user identity flown to backend services is protected.
• Single-Sign-On (SSO) or federated authentication solution is designed to access multiple applications with the same credentials or identity.
• Appropriate validation strategy is designed to validate inputs, both from the user and from sources such as services and other application interfaces.
• Sensitive data is encrypted where it may be exposed, especially over a network or communication channel, and you have considered using a digital signature to prevent tampering. In maximum security applications, you have considered encrypting volatile information stored in memory.

Offline / Occasionally Connected Considerations

• Asynchronous communication is used whenever possible for interacting with data and services over a network.
• Complex interactions with network-located data and services are minimized or eliminated.
• Data caching is designed to ensure that all of the data necessary for the user to continue working is available on the client when it goes offline.
• A mechanism to manage connections is designed that takes into account the environment in which your application operates, both in terms of the available connectivity and the desired behavior of your application as this connectivity changes.
• A store-and-forward mechanism is designed for communication so that messages are created, stored while the application is disconnected, and forwarded to their respective destinations when a connection becomes available.
• Data refresh mechanism is designed to deal with stale cached data, and preventing the Rich Client from using stale data.

Deployment Considerations

• The target physical deployment environment is identified, early in the planning stage of the design lifecycle.
• Environmental constraints that may impact your software design and architecture decisions are identified.
• Aspects of the software design that require certain infrastructure attributes are identified.