How To: Design Your Presentation Layer

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

Objectives

  • Learn how to choose a client type.
  • Determine the impact of client type on your presentation layer.
  • Learn strategies for data presentation.
  • Learn strategies for data and input validation.
  • Learn how and when to factor out business logic.
  • Learn strategies for accessing other layers.

Summary of Steps

  • Step 1 – Identify Your Client Type
  • Step 2 – Determine How You Present Data (Data Rendering Strategy)
  • Step 3 – Determine Your Data Validation Strategy
  • Step 4 – Determine Your Business Logic Strategy
  • Step 5 – Determine Your Strategy for Communication with Other Layers

Step 1 – Identify Your Client Type

Choose a client type to implement your presentation layer that satisfies your requirements and adheres to infrastructure and deployment constraints of your organization. You may choose multiple client types if a single type does not meet all of your user experience requirements.

There are following basic client types Rich Client, Web Client and Mobile Client:
  • Mobile Applications - can be developed as thin client or rich client applications. Rich client mobile application can support disconnected or occasionally-disconnected scenarios. Web or thin client applications support only connected scenarios. The device resources may prove to be a constraint while designing mobile applications.
  • Rich Client Applications - are normally developed as stand-alone applications with a graphical user interface that displays data using various controls. Rich client applications can be designed to support disconnected and occasionally-disconnected scenarios as the application runs on the client machine.
  • Rich Internet Applications - can be developed to support multiple platforms and multiple browsers, displaying rich media or graphical content. Rich internet applications run in a browser sandbox which restricts the access to devices on the client.
  • Web Applications - typically support connected scenarios and developed to support multiple browsers and multiple browsers.

Use following considerations when choosing a client type:

Consider using Mobile client type:
  • If your users depend on handheld devices.
  • If your application supports simple UI that is suitable for use on small screens.
  • If your application must support offline or occasionally connected scenario, consider using Mobile Rich client type.
  • If your application needs to be device independent and can depend on network connectivity, consider using Mobile Web Client.

Consider using Rich Client type:
  • If your application must support disconnected or occasionally disconnected scenarios.
  • If your application will be deployed on client PCs.
  • If your application must be highly interactive and responsive
  • If your application must provide rich functionality and user interaction with limited graphical or animation requirements.
  • If your applications must utilize the resources on the client PC.

Consider using Rich Internet Application (RIA) client type:
  • If your application must support rich media and provide a highly graphical display.
  • If your application must provide a rich, interactive, and responsive UI compared to a Web Application.
  • If your application will leverage client-side processing in a restricted manner.
  • If your application will utilize client-side resources in a restricted manner.
  • If you want the simplicity of a Web-based deployment model.

Consider using Web application client type:
  • If your applications does not require the rich UI and media support offered by a Rich Internet Application.
  • I f you want the simplicity of a Web-based deployment model.
  • If your application must be platform-independent.
  • If your application must be available over the Internet.

Step 2 – Determine How You Present Data (Data Rendering Strategy)

Choose the data format for your presentation layer and decide how you will present the data in your User Interface (UI). This choice is driven by the application requirements and constrained by your infrastructure and development capabilities.
  1. Choose a data format for your presentation data
The presentation data can be represented using XML, DataSets, typed DataSets, Arrays and Collection, or Custom classes. Use the following considerations to choose the data format for your scenario:
  • XML. XML format is useful when working with a Web client, where the data can be directly transformed to HTML using XSLT. XML is a particularly good choice when you are using Tree View and Grid View controls. It is also easy to store, serialize, and pass over communication channels.
  • DataSets. Use Datasets or Data Tables when you are working with data bound control such as Data Grids, List Boxes, and Dropdown lists.
  • Typed Datasets. Use typed DataSets when you want tight coupling with your business entities to avoid discrepancies due to database changes.
  • Arrays and Collection. Use an array or collection when you need to bind data to controls such as List Box or Dropdown List which take single column values.
  • Data Reader. Use a Data Reader for presenting streaming data when fully connected and data is accessed in a non-transactional, read-only, forward-only manner.
  • Custom Classes. Use a custom class if you want to represent your data as a complex object that maps directly to your business entities. For example, you could create a custom order object represent order data. You can also use a custom class to perform custom validation or implement custom properties.
  1. Present the data in the user interface
Use the following considerations when presenting data in the UI.
  • Asynchronous Data. Consider obtaining data on a background thread so as not to block the application UI.
  • Acquiring Data. Depending on the size of your application, you may have business and data access layers. If the data to be displayed requires extensive processing before display, create and utilize business layer functions to transform the data and then cache it in the presentation layer. If data will be displayed much as it appears in the database, consider directly accessing the data access layer.
  • Caching Data. Cache data that is static or costly to recreate. Cache data in ready-to-use format. In Web Farm scenarios, consider using a transactional resource manager such as SQL Server or a product that supports distributed caching.
  • Large Data Sets. Use UI Virtualization to display only a subset of values at one time. Use data bound controls like data grid, grid view to display tabular data, especially available in DataSet or DataTable formats. Use list boxes or drop down lists when displaying single column data. If possible, filter information at the server to reduce dataset size. Cache data that is static or particular costly to obtain or transform.
  • Localizing Data. If you need to support multiple locales, you must design your presentation layer to display localized data. Strings used in the UI should be loaded from localizable resource files. Values such as date and currency can be stored and displayed in different formats depending upon the user culture. Utilize data formatters on the controls that are part of the platform.
  • Updating Data. Data-bound controls in Web scenarios typically require additional code to propagate user changes to the data store. When updating data in a distributed system, do not initiate, participate or vote on atomic transactions. Since data may be stale, provide a mechanism to check, inform the user, and resolve the conflict.
  • Process Status. For long running or blocking processes in connected or occasionally connected scenarios, provide process status information on the UI.
  • User Specific Display. When each user will receive different data, capture and store user preferences. If users require authorization, display only the UI controls and that which users can view and act upon.

Step 3 – Determine Your Data Validation Strategy

Use data validation techniques to protect your system from untrusted input.
  1. Identify the trust boundaries
Draw a trust boundary around your presentation layer and the system that are outside of your direct control. Examples of trust boundaries include:
  • Data from databases or other data sources.
  • Data that is controlled by the client, such as user input or browser parameters.
  • Data from third-party components.
  • Data from components developed by another team in your organization.

Once you have determined your trust boundaries you can decide the level of trust you will allow across each boundary. For instance you may give some level of trust to components developed by another team in your organization but will not trust user input at all.
  1. Identify data inputs
After determining your trust boundaries you can identify the data input entry points that must be validated. For instance, the following inputs from a web client would need validation:
  • Form fields
  • Data received from un-trusted sources
  • Parameters – GET, POST data (query strings)
  • Hidden fields
  • View state

All of these data inputs require server-side data validation for security purposes. Some of the inputs such as form data may also require client-side validation to improve the user experience and responsiveness of the application. For example, you may want to warn the user of bad input using client side validation before validating it again on the server to block malicious access.
  1. Identify what to validate
Typically, all the input and data should be validated for length, range, format, and type.
  1. Choose the validation techniques
Once you have the identified the data input entry points that need to be validated you can determine a validation strategy for each. In general you should accept known good values (whitelist) rather than try to determine all the possible bad values that should be rejected. If you are not able to fully define the list of known good values, then you can supplement with a partial list of known bad values as a backstop. Use sanitization to mitigate the threats of cross-site scripting and other code injection techniques:
  • Accept known good (Whitelist or positive validation). Allow only the data which satisfies the matching criteria and all other data is rejected. Use this strategy in most cases as it is the safest which will allow only the data which satisfies the condition.
  • Reject known bad (Blacklist or negative validation). Allow data which doesn’t contain a known set of characters. Use this strategy cautiously as the list of known invalid characters may not be complete and opens up a hole.
  • Sanitize: Eliminate or translate characters in an effort to make the input safe. Similar to the negative validation the list of unsafe characters may not be complete.

Use client side validation to catch common errors from legitimate users and improve the user experience of your application. Do not use client-side validation as a security check or as a way to make decisions that have security consequences. Since a determined attacker can bypass client-side validation, use server-side validation to reduce the threat of malicious attack.
  • Client-side data validation. Implement client-side validation to save time and bandwidth. Validation can be implemented using JavaScript code that executes when the user attempts to submit the page. The error messages are displayed to the user, and the post back may be prevented.
  • Server-side data validation. Even when you implement client-side validation, you must always implement server-side validation as well, because a malicious user may intercept a HTTP request (in the case of a Web application) and modify it. In addition, some browsers may not support scripting and so will not execute the validation code. Implement the logic to validate the input data when the form is submitted. Consider implementing server side validation in separate user process components to allow reuse of the logic.

When displaying validation error messages, ensure that you do not expose information that may be useful to an attacker. For example, if a user fails authentication when entering a user name and password, do not indicate which of the values is invalid. Doing so will confirm to an attacker that one of the values is correct - perhaps indicating that there is an account with the user name they specified and they then need to discover only the password.

Step 4 – Determine Your Business Logic Strategy

Factor your business logic to decouple business logic from presentation layer code. This will improve the maintainability of your application, making it easier to modify your business logic without presentation layer impact.

How you factor your business logic is driven by the complexity of your application. Review each option and choose the one which best suits your scenario:
  • UI Validation. For simple applications where the business logic is only used to validate user inputs, you can choose to place the business logic in the UI components. However, be careful not to mix any domain specific business logic within your UI components.
  • Business Process Components. For more complex applications that support transactions, and contain basic business logic that extends beyond UI validation, consider separating the business logic into separate components that are used by the UI components.
  • Domain Model. For complex enterprise applications, where the business logic is shared among multiple applications, consider separating the business components into their own logical layer. If you separate the business components into a separate layer, you can then choose to deploy the business layer onto a separate physical tier to improve scalability and allow reuse by other applications.
  • Rules Engine. In applications that must support complex validation, process orchestrations, and domain logic, consider placing your business logic in a rules engine such as BizTalk Server.

Step 5 – Determine Your Strategy for Communication with Other Layers

You may have multiple layers in addition to your presentation layer, such as a data access layer and a business layer. In this case, you must determine a strategy for communication between the presentation layer and the other layers in your application. If you have a separate business layer, your presentation layer will communicate with the business layer. If you do not have a business layer, your presentation layer will communicate directly with the data access layer.

Use the following techniques to access other layers:
  • Direct .NET Calls. If the layer you are communicating with is on the same physical tier as the presentation layer, you can make direct .NET method calls.
  • Web Services. If you want to share the data access or business logic with other applications or decoupling is important, you should choose a Web service interface.
  • If your business logic or data access logic will be consumed by the presentation layer within your intranet, consider WCF using the TCP protocol.
  • If your business logic or data access logic will be consumed by your presentation layer across the Internet, consider WCF using the HTTP protocol.
  • If your business logic or data access logic performs long-running calls, consider asynchronous communication using WCF and message queuing.

Security Considerations

  • Make sure that the application does not allow internal exception information to propagate beyond the application UI boundary. Exceptions should be caught and logged on the server and, if necessary, generic error messages should be returned to the client.
  • Client-side validation can be used to reduce the number of round trips to the server, but do not rely on it for security because it is easy to bypass. Validate all input at the server.
  • Sensitive data communicated across trust boundaries should be encrypted and signed.

Performance Considerations

  • If your application must be scalable, make sure you do not mix logic for different areas of functionality (such as presentation logic and business logic).
  • Ensure that logically related entities in the presentation layer, such as classes and methods, are grouped together appropriately.
  • You should cache data in the presentation layer that will be displayed to the user. For example, you can cache the information that is displayed in a stock ticker.
  • You should generally avoid caching per-user data, unless the user base is very small and the total size of the data cache does not require too much memory. However, if users tend to be active for a while, caching per-user data for short time periods may be the appropriate approach.
  • Do not query for more data than you need to display; instead use paging to extract just the records you will display.
  • Use ViewState cautiously because it increases the volume of data sent for each roundtrip, and may reduce the performance of the application.

Additional Resources

Last edited Dec 17, 2008 at 8:42 PM by prashantbansode, version 2

Comments

No comments yet.