Rich Internet Application (RIA) Design Checklist

From Guidance Share
Jump to navigationJump to search

Design Considerations

  • The application is designed for running in the browser sandbox.
  • The application is designed for supporting multiple browsers and operating systems.
  • The application detects when the browser plug-in is not installed and takes the appropriate action.
  • The application provides alternative for clients that do not have RIA support.
  • The application uses mechanisms to increase performance and responsiveness.

Business Layer

  • Business logic is located on the server and exposed through Web services.
  • Business logic is moved to the client, only when it improves the overall system performance or makes the UI more responsive.
  • Business logic on the client is deployed in a separate assembly that the application can load and update independently.
  • Logic that is duplicated on the client and the server is written in the same code language where possible.
  • Sensitive business logic deployed on the client is encrypted.


  • Components and objects that are not likely to change during a session are cached on the client using the browser cache.
  • Information that changes during a session, or which should persist between sessions, is cached in specific RIA local storage.
  • Application modules are intelligently divided for efficient installation, updates, and loading.
  • The application loads stubs dynamically at start-up and then loads additional functionality in the background.
  • The application uses events to intelligently pre-load modules just before they are required.
  • The application checks the local RIA storage, before writing the data, and asks the user to increase the storage, if it is not large enough.


  • Background threads and asynchronous execution are used for long-running code routines to avoid blocking the UI thread.
  • Compatible bindings are used for the RIA applications and services it calls.
  • The cross-domain configuration mechanism is used to allow the application to access a server other than the one from which it was downloaded.
  • Sockets are used to proactively push data to the client where client polling would cause heavy server load.
  • Sockets are used to push information to the server when this is significantly more efficient than using Web services; for example, real-time multi-player gaming scenarios utilizing a central server.


  • Native RIA controls are used where possible.
  • Third-party RIA-specific controls are used when an appropriate native control is not available.
  • A windowless RIA control in combination with an HTML or Windows Forms control supporting required functionality is used when a native or third-party RIA control is not available.
  • Control sub-classing is not used to extend functionality; instead behaviors are attached to existing controls where the RIA technology supports it.


  • Composite View pattern is used to combine modular, atomic component parts to create composite views.
  • Composition is used for interfaces that gather information from many disparate sources that are user-configurable or change frequently.
  • RIA and the existing HTML are mixed on the same page to migrate an existing HTML application, in order to minimize application reengineering.

Data Access

  • The number of round-trips to the server is minimized, while still providing a responsive user interface.
  • Data is filtered at the server rather than at the client to reduce the amount of data that must be sent over the network.
  • Services are used to access data for operation-based applications.

Exception Management

  • Exceptions are not used to control business logic.
  • Exceptions are caught only if they can be handled.
  • Exception propagation strategy is designed to log and transform exceptions at boundary layers before passing to the next layer.
  • The application uses try/catch blocks to trap exceptions in synchronous code.
  • Exception handling for asynchronous service calls is located in the separate handler.
  • Unhandled exceptions passed to the browser are trapped and a user friendly error message is displayed.
  • The server is notified of client exceptions, whenever required.
  • The application displays user-friendly error messages.


  • Business critical and system critical events are logged.
  • Each user has separate logs; the different user logs on the machine are combined.
  • Client logs are transferred to the server for processing.
  • The application checks the maximum size limit of isolated storage, before writing the data, and asks the user to increase the storage, if it is not large enough.
  • The design enables logging and transferring logs to the server when exceptions are encountered.

Media and Graphics

  • Streaming media and video are displayed in the browser and not by invoking a separate player utility.
  • Media objects are positioned on whole pixels and presented in their native size to maximize performance.
  • Adaptive streaming is used to gracefully and seamlessly handle varying bandwidth issues.
  • The vector graphics engine is utilized to maximize drawing performance.
  • The application considers the hardware acceleration limitations when designing graphics-intensive application.


  • RIA client for mobile device is designed considering the RIA plug-in implementation available for the device.
  • A single or similar codebase is used to maximize cross-platform capabilities.
  • The UI layout is designed considering the smaller screen size.


  • The application design supports "write once, run everywhere" principle.
  • The application does not use features available only on one platform, such as Windows Integrated Authentication to support multiple platforms.
  • Development languages that are supported for both Rich Clients and RIAs are used.
  • The application uses native RIA code libraries.


  • Media objects are positioned on whole pixels and presented in their native size to avoid anti-alias issues that may cause fuzziness.
  • The browser's forward and back button events are trapped to avoid unintentional navigation away from your page.
  • Deep linking methods are used for multi-page UIs to allow unique identification and navigation to individual application pages.
  • The application manipulates the browser's address text box content, history list, and back and forward buttons in multi-page UIs to implement normal Web page-like navigation.

State Management

  • Client’s isolated storage is used to persist state between sessions.
  • Client state is stored on the server, if loss of state on the client would be catastrophic to the application’s function.
  • Client state is stored on the server, if the client requires recovery of application state when using different accounts, or when running on other hardware installations.
  • The client and server are synchronized at intelligent intervals, or at the end of a session when storing state on the server is necessary.
  • Synchronization of stored state is verified between the client and server at startup, and inconsistencies are intelligently handled.
  • RIA is designed for multiple concurrent sessions if multiple RIA instances can be initialized.


  • Client-side validation is used for better user experience. Server-side validation is used for security. Client-specific validation rules are cached in isolated storage.
  • All client-controlled data is revalidated it on the server.
  • The validation strategy is designed to constrain, reject and sanitize data.
  • Single service calls perform validation rules on the server when the rules require access to server resource.
  • Large volumes of client-side validation code are located in a separate downloadable module.

Performance Considerations

  • Components and objects that are not likely to change during a session are cached on the client using the browser cache.
  • Information that changes during a session, or which should persist between sessions is cached in specific RIA local storage.
  • The application loads stubs dynamically at start-up and then loads additional functionality in the background.
  • Code routines that cause the heaviest server load or have the most impact on UI responsiveness are moved to or cached on the client.
  • Scenario-based profiling is used to discover and target routines that cause the heaviest server load, or that have a major impact on UI responsiveness.
  • Media objects are positioned on whole pixels and presented in native size.

Security Considerations

  • Sensitive data stored locally is encrypted using the platform encryption routines.
  • An exception management strategy is used to prevent exposure of sensitive information through unhandled exceptions.
  • Sensitive business logic is implemented through Web services or obfuscated when stored on the client.
  • Dynamic loading of resources, and overwriting or clearing objects from memory, is used to minimize the amount of time that sensitive data is available on the client.

Deployment Considerations

  • The application can handle the scenario where the RIA browser plug-in is not installed.
  • The application can manage redeployment of modules when still running on a client.
  • The application is divided into logical modules that can be cached separately, and can be replaced easily without requiring the user to download the entire application again.
  • The application components are versioned.

Distributed Deployment Considerations

  • Business logic that is shared by other applications is deployed using the distributed pattern.
  • A firewall is installed between the client and the business layer.
  • Access to other domains is enabled using a crossdomain.xml file.
  • The presentation layer does not initiate, participate in, or vote on atomic transactions.
  • Business logic uses a message-based interface.
  • Sensitive data passed between different tiers is protected.

Load Balancing Considerations

  • The application avoids server affinity where possible.
  • The application stores all state on the client and uses stateless business components.
  • Load balancing is implemented for redirection of requests to the servers in an application farm.

Web Farm Considerations

  • Clustering is used to reduce the impact of hardware failures.
  • The database is partitioned across multiple database servers when the application has high I/O requirements.
  • The Web farm routes all requests for the same user to the same server when the application must support server affinity.
  • An out-of-process session service or a database server is used in the Web farm unless server affinity is implemented for all clients.