This project is read-only.
Note that the information on this page is the BETA 1 of a guide that is now released. See http://www.codeplex.com/AppArchGuide for the latest PDF and HTML content.

Chapter 12 – Presentation Layer Guidelines

- J.D. Meier, Alex Homer, David Hill, Jason Taylor, Prashant Bansode, Lonnie Wall, Rob Boucher Jr, Akshay Bogawat

Overview

The presentation layer contains the components that implement and display the user interface, and manage user interaction. This layer includes controls for user input and display, in addition to components that organize user interaction. The following diagram shows how the presentation layer fits into a common application architecture.

PresentationLayer.PNG

Presentation Layer Components

  • User interface (UI) components. User interface components provide a way for users to interact with the application. They render and format data for users. They also acquire and validate data input by the user.
  • User process components. User process components synchronize and orchestrate user interactions. Separate user process components may be useful if you have a complicated user interface. Implementing common user interaction patterns as separate user process components allows you to reuse them in multiple user interfaces.

Approach

Use the following steps to help organize your thinking when designing the presentation layer:
  1. Identify your client type. Choose a client type that satisfies your requirements and adheres to the infrastructure and deployment constraints of your organization.
  2. Determine how you will present data. Choose the data format for your presentation layer and decide how you will present the data in your User Interface (UI).
  3. Determine your data validation strategy. Use data validation techniques to protect your system from un-trusted input.
  4. Determine your business logic strategy. Factor out your business logic to decouple it from your presentation layer code.
  5. Determine your strategy for communication with other layers. If your application has multiple layers, such as a data access layer and a business layer, determine a strategy for communication between your presentation layer and other layers.

Design Considerations

Use the following principles when designing the presentation layer:
  • Choose the appropriate UI technology. Determine if you will implement a Rich (Smart) Client, a Web client, or a Rich Internet Application (RIA).
  • Implement the relevant patterns. Review the presentation layer patterns for proven solutions to common presentation problems.
  • Design for separation of concerns. Use dedicated UI components that focus on rendering and display. Use dedicated presentation entities to manage the data required to present your views. Use dedicated UI process components to manage the processing of user interaction.
  • Consider human interface guidelines. Review your organization's guidelines for user interface design. Review established user interface guidelines based upon the client type and technologies that you have chosen.
  • Adhere to user-driven design principles. Before designing your presentation layer, understand your customer. Use surveys, usability studies, and interviews to determine the best presentation design to meet your customer’s requirements.

Presentation Layer Frame

Category Common issues
Caching Caching volatile data.
Caching unencrypted sensitive data.
Incorrect choice of caching store.
Failing to choose a suitable caching mechanism for use in a Web farm.
Assuming that data will still be available in the cache – it may have expired and been removed.
Composition Failing to consider use of patterns and libraries that support dynamic layout and injection of views and presentation at runtime.
Using presentation components that have dependencies on support classes and services instead of considering patterns that support run-time dependency injection.
Failing to use the Publish/Subscribe pattern to support events between components.
Failing to properly decouple the application as separate modules that can be added easily.
Exception Management Failing to catch unhandled exceptions.
Failing to clean up resources and state after an exception occurs.
Revealing sensitive information to the end user.
Using exceptions to implement application logic.
Catching exceptions you do not handle.
Using custom exceptions when not necessary.
Input Failing to design for intuitive use, or implementing over-complex interfaces.
Failing to design for accessibility.
Failing to design for different screen sizes and resolutions.
Failing to design for different device and input types, such as mobile devices, touch-screen, and pen and ink enabled devices.
Layout Using an inappropriate layout style for web pages.
Implementing an overly-complex layout.
Failing to choose appropriate layout components and technologies.
Failing to adhere to accessibility and usability guidelines and standards.
Implementing an inappropriate workflow interface.
Failing to support localization and globalization.
Navigation Inconsistent navigation.
Duplication of logic to handle navigation events.
Using hard-coded navigation.
Failing to manage state with wizard navigation.
Presentation Entities Defining entities that are not necessary.
Failing to implement serialization when necessary.
Request Processing Blocking the user interface during long-running requests.
Mixing processing and rendering logic.
Choosing an inappropriate request-handling pattern.
User Experience Displaying unhelpful error messages.
Lack of responsiveness.
Over-complex user interfaces.
Lack of user personalization.
Lack of user empowerment.
Designing inefficient user interfaces.
UI Components Creating custom components that are not necessary.
Failing to maintain state in the MVC pattern.
Choosing inappropriate UI components.
UI Process Components Implementing UI process components when not necessary.
Implementing the wrong design patterns.
Mixing business logic with UI process logic.
Mixing rendering logic with UI process logic.
Validation Failing to validate all input.
Relying only on client-side input validation. You must always validate input on the server or in the business layer as well.
Failing to correctly handle validation errors.
Not identifying business rules that are appropriate for validation.
Failing to log validation failures.

Caching

Caching is one of the best mechanisms you can use to improve application performance and UI responsiveness. Use data caching to optimize data lookups and avoid network round trips. Cache the results of expensive or repetitive processes to avoid unnecessary duplicate processing.

When designing your caching strategy, consider the following guidelines:
  • Avoid distributed coherent caches.
  • Do not cache volatile data.
  • Do not cache sensitive data unless you encrypt it.
  • When working with an in-memory cache, consider caching data in a ready-to-use format. For example, cache specific objects instead of caching raw database data.
  • Differentiate between cached data and state data.
  • Use absolute expiration for dynamic data which is set to change after particular time..
  • Use sliding expiration for information which will expire after a certain period of inactivity..
  • Be deliberate while choosing time interval for time-based expiration.. Selecting a short value will require more round trips, whereas by selecting a higher value you might be working with stale data.
  • Consider automatically removing (scavenging) when working with an in-memory cache.
  • Consider manually removing (explicit flushing) when working with disk-based cache.
  • Do not depend on data still being in your cache. It may have been removed.
  • If you use a persistent cache, consider proactive loading. You should proactively load the data only if you know that it would be static for certain period and the lifetime is known or you have connectivity issues like slow or unreliable network.
  • If you use an in-memory cache, avoid proactive loading unless the items are expensive to recreate.

Composition

Consider whether your application will be easier to develop and maintain if the presentation layer uses independent modules and views that are easily composed at runtime. Composition patterns encourage dynamic loading of presentation logic, and creation of views and the presentation layout at runtime. These patterns also help to minimize code and library dependencies that would otherwise force recompilation and redeployment of a module when the dependencies change. Composition patterns help you to implement sharing, reuse, and replacement of presentation logic and views.

When designing your composition strategy, consider the following guidelines:
  • Use dynamically-loaded and reusable views to simplify the design, and improve performance and maintainability.
  • Remove dependencies by utilizing patterns such as Dependency Injection, which support dynamic loading and easy replacement of modules.
  • If you need to allow dynamically loaded modules to communicate with each other, consider implementing the Publish/Subscribe pattern. This will lower the coupling between the modules and improve testability.
  • If you need to support menu and command-driven interaction, consider implementing the Command pattern.
  • Consider implementing the View Injection pattern instead of the View Discovery pattern as a strategy for composing your UI.
  • If you are composing dynamic Web pages, consider implementing the Template View pattern to improve reuse and consistency. In ASP.NET, you can use Master Pages for this.
  • If you are building a view from modular atomic components, consider implementing the Composite View pattern.

Exception Management

Design a centralized exception management mechanism for your application that catches and throws exceptions consistently. Pay particular attention to exceptions that propagate across layer or tier boundaries, as well as exceptions that cross trust boundaries. Design for unhandled exceptions so they do not impact application reliability or expose sensitive information.

When designing your exception management strategy, consider the following guidelines:
  • Use user-friendly error messages to notify users of errors in the application.
  • Avoid exposing sensitive data in error pages, error messages, log files and audit files.
  • Implement a global exception handler that displays a global error page or an error message for all unhandled exceptions.
  • Differentiate between system exceptions and business errors. In case of business errors, display a user-friendly error message and allow user to retry the operation. In case of system exceptions, check if it is caused because of issues like system or database failure, display user-friendly error message and log the error message which will help in troubleshooting.
  • Create custom exceptions only if there is no suitable existing exception type, or if you need to disambiguate from existing exceptions.
  • Avoid using exceptions to control application logic.

Input

Design a user input strategy based upon your application input requirements. For maximum usability, follow the established guidelines defined in your organization, and the many established industry usability guidelines based on years of user research into input design and mechanisms.
When designing your input collection strategy, consider the following guidelines:
  • Use forms-based input controls for normal data collection tasks.
  • Use a document-based input mechanism for collecting input in Office-style documents.
  • Implement a wizard-based approach for more complex data collection tasks, or input that requires a workflow.
  • Determine your requirements for ink, speech or other device-dependent input techniques.
  • Design with localization in mind.
  • Design with accessibility in mind. You should consider users with disabilities while designing input strategy, for example, implement text-to-speech software for blind users or enlarge text and images for users with poor sight.

Layout

Design your UI layout so that the layout mechanism itself is separate from the individual UI components and UI processing components. When choosing a layout strategy, consider whether you will have a separate team of designers building the layout, or whether the development team will create the UI. If designers will be creating the UI, choose a layout approach that does not require code or the use of development-focused tools.

When designing your layout strategy, consider the following guidelines:
  • Choose a layout methodology and design tools. Layout methodologies include table-based, CSS-based, grid-based, and template based.
  • Design with user personalization in mind.
  • Design with localization in mind.
  • Use a common layout for all elements of your UI to maximize accessibility and ease of use.
  • Design layouts that comply with industry and established standards.
  • Design Web layouts that are optimized for search engines (Search Engine Optimization or SEO).

Navigation

Design your navigation strategy so that users can navigate easily through your screens or pages, and so that you can separate navigation from presentation and UI processing. Ensure that you display navigation links and controls in a consistent way throughout your application to reduce user confusion and hide application complexity.

When designing your navigation strategy, consider the following guidelines:
  • Determine your screen or page navigation strategy. For example, the use of toolbars and menus, a sitemap, and master pages.
  • Separate navigation from processing.
  • Determine how you will preserve navigation state.

Presentation Entities

Use presentation entities to store the data you will use in your presentation layer to manage your views. Presentation entities are not always necessary; use them only if your data sets are sufficiently large and complex to require separate storage from the UI controls.

When designing presentation entities, consider the following guidelines:
  • Determine if you need presentation entities.
  • If you are working with data-bound controls, consider using DataSets, arrays, or collections as your presentation entity format.
  • If you want to map data directly to business entities, use a custom class for your presentation entities.
  • Do not add business logic to presentation entities.
  • If you need to perform any input data validation consider adding it in your presentation entities.

Request Processing

Design your request processing with user responsiveness in mind, as well as code maintainability and testability.

When designing request processing, consider the following guidelines:
  • Be careful to not block the UI when making requests, especially long-running requests.
  • Do not mix your processing and rendering logic.
  • Do not implement the request processing logic in the view.

User Experience

Good user experience can make the difference between a usable application and one that is unusable. Carry out usability studies, surveys, and interviews to understand what users require and expect from your application, and design with these results in mind.

When designing for user experience, consider the following guidelines:
  • Keep the users' perspective in mind when designing error messages.
  • Focus on UI responsiveness.
  • In a Rich Client or desktop application, avoid blocking the user thread for long periods.
  • In a Rich Internet Application (RIA), avoid synchronous processing where possible.
  • When developing a Web application, utilize AJAX to improve responsiveness, and reduce postbacks and page reloads.
  • Do not design overloaded or over-complex interfaces. Provide a clear path through the application for each key user scenario.
  • Design for user personalization, localization, and accessibility.
  • Design for user empowerment. Allow the user to control how they interact with the application, and how it displays data to them.

UI Components

UI components are the controls and components used to display information to the user and accept user input. Be careful not to create custom controls unless it is necessary for specialized display or data collection.

When designing UI components, consider the following guidelines:
  • In Windows Forms and Compact Framework applications, store UI state locally as entities or individual values.
  • In ASP.NET applications, allow ASP.NET to manage state for UI controls and store UI state in the ViewState, Session, or Application objects depending on the scope required.
  • In ASP.NET Mobile applications, allow ASP.NET to store state in the user's Session to minimize impact on the device.
  • Take advantage of the data-binding features of the controls you use in the user interface.
  • Create custom controls or use third party controls only for specialized display and data collection tasks.
  • In WPF and Silverlight, utilize Data Templates over User Controls as much as possible.
  • In WPF and Silverlight, implement the Presentation Model pattern to manage UI state.

UI Processing Components

UI process components synchronize and orchestrate user interactions. UI processing components are not always necessary. Create them only if you need to perform significant processing in the presentation layer that must be separated from the UI controls. Be careful not to mix business and display logic within the process components; they should be focused on organizing user interactions with your UI.

When designing UI processing components, consider the following guidelines:
  • Choose relevant patterns, such as MVC, Supervising Controller, Passive View, or Presentation Model.
  • Decouple the rendering and display from the processing that must occur in the presentation layer.
  • Avoid including business rules in the UI processing components. Business rules belong in the business layer.
  • Where the UI requires complex processing, use separate UI process components to decouple this processing from the UI.
  • Where the UI requires complex workflow support, create separate workflow components that use a workflow system such as Windows Workflow or a custom mechanism.

Validation

Designing an effective input and data validation strategy is critical to the security of your application. Determine the validation rules for user input as well as for business rules that exist in the presentation layer.

When designing your input and data validation strategy, consider the following guidelines:
  • Validate all input data client-side where possible to improve interactivity and reduce errors caused by invalid data.
  • Do not rely on just client side validation. Use server-side validation as well to constrain input for security purposes and to make security-related decisions.
  • Centralize your validation approach, if it could be re-used.
  • Constrain, reject, and sanitize all input.
  • Use the built-in validation controls where possible.
  • Consider storing validation rules in configuration. The Enterprise Library Validation Application Block is useful in this scenario.
  • In Web applications, consider using AJAX to provide real-time validation.

Pattern Map

Area Relevant Patterns
Caching Cache Dependency
Page Cache
Composition Composite View
Dependency Injection
Template View
Transform View
Two-step View
Exception Management Exception Shielding
Navigation Front Controller
Page Controller
UI Processing Components Model View Controller (MVC)
Passive View
Presentation Model (Model-View-ViewModel)
Supervisor Controller

Key Patterns

  • Composite View – Combine individual views into a composite representation.
  • Front Controller – Consolidate request handling by channeling all requests through a single handler object, which can be modified at runtime with decorators.
  • MVC – Separate the data from the user interface and the user input processing.
  • Page Controller – Accept input from the request and handle it for a specific page or action on a Web site.
  • Passive View – Reduce the view to the absolute minimum by allowing the controller to process user input and maintain the responsibility for updating the view.
  • Presentation Model – Move all view and state logic out of the view and render the view through data-binding and templating.**
  • Supervising Controller – A variation on MVC in which the controller handles complex logic, in particular coordinating between views, but the view is responsible for simple view-specific logic.
  • Template View – Implement a common template view, and derive or construct views using this template view.
  • Transform View – Transform the data passed to the presentation tier to HTML for display in the UI.
  • Two-Step View** – Transform the model data into a logical presentation without any specific formatting and then convert that logical presentation to add the actual formatting required.

Technology Considerations

The following guidelines apply to specific types of application and technology.

Mobile applications

  • Use the Windows Compact Framework for full-featured connected, occasionally-connected, and disconnected applications.
  • Use ASP.NET Mobile Forms and Mobile Controls for connected applications that require WAP, cHTML, or similar rendering formats.
  • Use Silverlight for connected applications that require rich media support.

Rich Client Applications

  • Use Windows Forms for good performance, interactivity, and design support in Visual Studio.
  • Use Windows Forms combined with WPF User Controls for applications that require islands of rich media support.
  • Use WPF for applications that are highly graphical and support rich media and presentation features.
  • Use the Composite Application Guidance for building composite applications in WPF.
  • Use XAML Browser Applications (XBAP) for applications that are downloaded from a Web server and then execute on the client.
  • If you are using WPF, consider using the Presentation Model (Model-View-ViewModel) pattern.
  • If you are using WPF, consider using WPF Commands to communicate between your View and your Presenter or ViewModel.
  • If you are using WPF, consider implementing the Presentation Model pattern by using DataTemplates over User Controls to give designers more control.

Rich Internet Applications (RIA)

  • Use Silverlight for connected browser-based applications that have broad reach cross-platform, are highly graphical, and support rich media and presentation features.
  • If you are using Silverlight, consider using the Presentation Model (Model-View-ViewModel) pattern.

Web Applications

  • Use ASP.NET for connected applications exposed through a Web browser or specialist user agent.
  • Use ASP.NET with AJAX for connected Web applications that require increased interactivity or background processing with fewer page reloads.
  • Use ASP.NET with Silverlight controls for connected Web applications that include islands of rich media content and interactivity.
  • Use the ASP.NET MVC Framework to implement a control-centric model with separate controllers and improved testability.
  • In ASP.NET, consider using Master Pages to implement a consistent UI.

Additional Resources

Last edited Dec 16, 2008 at 8:18 AM by rboucher, version 3

Comments

No comments yet.