Дизайн Уровня представленияContentsДизайн Уровня представления 1
Компоненты уровня представления 1
Дизайн Уровня Представления 2
Специфические проблемы дизайна уровня представления 3
Кеширование 4
Communication 4
Composition 5
Exception Management 5
Navigation 5
User Experience 6
User Interface 6
Validation 7
Design patterns 7
Sources 8Компоненты уровня представления
Уровень представления содержит компоненты, которые реализуют и отображают интерфейс пользователя и отвечают за взаимодействие с пользователем.
Обычно уровень представления включает следующее:
Компоненты интерфейса пользователя. Это визуальные элементы приложения, которые отображают информацию пользователю и используются для ввода пользователем данных.
Компоненты логики представления. Логика представления это код приложения, который определяет логически поведение и структуру приложения независимо от способа реализации интерфейса пользователя. При реализации паттерна Раздельного представления (Separated Presentation pattern), компоненты логики представления могут включать Представитель(Presenter), Модель Представления(Presentation Model), и Модель Вида???(View Model). Уровень представления включает также компоненты модели представления (Presentation Layer Model), инкапсулирующие данные бизнес - уровня, или компоненты сущности представления (Presentation Entity), которые инкапсулируют бизнес-логику и данные в форме, удобной для использования на уровне представления.
Дизайн Уровня Представления
Дизайн уровня представления включает следующие шаги:
Определение типа клиента. Необходимо выбрать тип клиента, который будет удовлетворять требованиям и соответствовать инфраструктуре и ограничениям внедрения в вашей организации.
Выбор технологии уровня представления. Необходимо определить функциональность пользовательского интерфейса и уровня представления в общем и выбрать такую технологию которая удовлетворяла бы требованиям и была доступна для выбранного типа клиента. На этом этапе, если доступные технологии не подходят для выбранного типа клиента, то возможен пересмотр выбора клиента.
Дизайн интерфейса пользователя. Необходимо решить, должен ли интерфейс быть модульным, и, определить способ разделения функциональности на уровне представления. Рассмотрите паттерны представления, такие как Модель представления(Presentation Model), Модель - Представление-Контроллер(MVC), и (???) MVP.
Определите стратегию проверки вводимых данных. Используйте методы проверки ввода чтобы защитить систему от подозрительных входных данных. Определите стратегию обработки исключений и протоколирования.
Определите стратегию бизнес-логики. Выделите бизнес логику, чтобы отделить ее реализацию от кода уровня представления. Это позволит упростить дальнейшее сопровождение приложения, так чтобы модификации бизнес-логики не влияли на уровень представления. Выбор способа зависит от сложности приложения, общепринятыми являются следующие подходы:
Интерфейс проверки ввода (UI Validation). Для случая простых приложений, где бизнес-логика используется для проверки ввода пользователя, функциональность бизнес логики может быть реализована в компонентах пользовательского интерфейса. Однако надо надо воздерживаться от смешения любой бизнес-логики, которая не относится к проверке ввода с компонентами интерфейса пользователя.
Компоненты Бизнес-процесса. Для более сложных приложений, например, приложений, использующих транзакции, или приложений в которых использование бизнес-логики выходит за рамки простой проверки ввода, бизнес-логика должны располагаться в отдельныъх компонентах, которые сипользуются компонетами пользовательского интерфейса.
Модель области применения(Domain Model). Для сложных корпоративных приложений, где бизнес-логика совместно сипользуется множеством приложений, необходимо рассмотреть вариант выделения бизнес-компонетов в отдельный логический уровень. Этот подход позволит разместить слой бизнес-логики на отдельном физическом уровне (physical tier) чтобы улучшить расширяемость и возможность повторного использования другими приложениями.
Модуль управления бизнес-правилами (Rules Engine). В приложениях, которые должны поддерживать комплексную проверку, управление процессами, логику области применения, бизнес-логика может быть реализована модулем управления бизнес-правилами.
Определение стратегии коммуникации с другими серверами. Если приложение состоит из множества уровней, таких как уровень доступа к данным и бизнес-логики, определите стратегию коммуникации между уровнем представления и другими уровнями.Если уровни бизнес логики и представления реализованы разделно, то уровень представления будет сообщаться с уровнем бизнес-логики. Если бизнес-уровень отсутствует, то уровень представления будет сообщаться непосредственно с уровнем доступа к данным. Как правило, для доступа к остальным уровням используются следующие способы:
Явный вызов функций(Direct method calls). Если логический уровень (layer), с которым выполняется обмен данными находится на том же физическом уровне (tier), то может использоваться явный вызов функкций .
Web services. Если доступ к данным или бизнес-логике должен разделяться между множеством приложений, то имеет смысл использовать интерфейс веб — сервисов ( Web service) в случае, если бизнес логика и данные расположены на отдельных с редставлением физических уровнях, или их разделение играет важно .
Существует несколько ключевых принципов, которые должны использоваться во время дизайна уровня представления. Это:
Выбор подходящей технологии UI. Определите, будете ли вы реализовывать «толстый» клиент (rich/smart), Web-клиент, или интернет-приложение (Rich Internet application). Решение должно быть обосновано требованиями пприложения и ограничениями - организационными и инфраструктуры.
Использование подходящих шаблонов. Используйет готовые паттерны уровня представления в качестве проверенных решений существующих проблем. Основной паттерн Раздельного Представления (Separated Presentation), отделяющий функциональность, специфичную для уровня представленияw от логики остального приложения может быть применен ко всем типам приложений. Специфические паттерны MVC, MVP, и Упраляющий Презентер ( Supervising Presenter) широко используются на уровне представления приложений использующих «толстый» клиент (rich client) и интернет приложений (RIA). Вариации паттернов Model-View-Controller (MVC) и Model-View-Presenter (MVP) могут использоваться Web- приложениями.
Разделение функциональности. Для отображения, управления данными, и обработки коммуникации с пользователем должны использоваться специфические компоненты предназначенные именно для этих целей.
Применение стандартов построения пользовательского интерфейса. Необходимо учитывать стандарты организации по построению пользовательских интерфейсов, а так же рекомендации по построению пользоваельского интерфейса для для выбранного типа клиента и технологии.
Применение принципа дизайна, ориентированного на пользователя. Перед разработкой уровня представления необходимо изучить потребности пользователя при помощи опросов, интервью и оценки удобства использования (usability study).
Специфические проблемы дизайна уровня представления
Существует несколько распространенных проблем, которые возникают при разработке уровня представления. Эти проблемы классифицируются по областям проектирования в которых они возникают:
Кеширование
Коммуникации
Композиция
Управление исключениями
Навигация
User Experience
Интерфейс пользователя
Проверка вводимых данных(Validation )
Кеширование
Кеширование один из основных механизмов, которые применяются для увеличения производительности приложения уменьшения времени взаимодействия с интерфейсом пользователя. Кеширование данных может использоваться для оптимизации поиска в данных и уменьшения взаимодействия по сети, а также промежуточного сохранения результатов трудоемких и повторяющихся процессов во избежание их дублирования. При определении стратегии кеширования должно учитываться следующее:
Choose the appropriate location for your cache, such as in memory or on disk. If your application is deployed in Web farm, avoid using local caches that must be synchronized. In general, for Web and application farm deployments, consider using a transactional resource manager such as Microsoft SQL Server®, or a product that supports distributed caching such as the Danga Interactive "Memcached" technology or the Microsoft "Velocity" caching mechanism. However, if the variation between individual servers is not critical, or the data changes very slowly, in-memory caching may be appropriate.
Consider caching data in a ready to use format when working with an in-memory cache. For example, use a specific object instead of caching raw database data. However, avoid caching volatile data as the cost of caching may exceed that of recreating or fetching the data again if it constantly changes.
Do not cache sensitive data unless you encrypt it.
Do not depend on data still being in your cache; it may have been removed. Also, consider that the cached data may be stale. For example, when conducting a business transaction, you may want to fetch the most recent data to apply to the transaction rather than use what is in the cache.
Consider authorization rights for cached data. Only cache data for which you can apply appropriate authorization if users in different roles may access the data.
If you are using multiple threads, ensure that all access to the cache is thread-safe.
For more information on caching techniques, see Chapter 17 "Crosscutting Concerns."
Communication
Handle long-running requests with user responsiveness in mind, as well as code maintainability and testability. Consider the following guidelines when designing request processing:
Consider using asynchronous operations or worker threads to avoid blocking the UI for long-running actions in Windows Forms and WPF applications. In ASP.NET, consider using AJAX to perform asynchronous requests. Provide feedback to the user on the progress of the long running action. Consider allowing the user to cancel the long running action.
Avoid mixing your UI processing and rendering logic.
When making expensive calls to remote sources or layers, such as when calling Web services or querying a database, consider if it makes more sense to make these calls chatty (many smaller requests) or chunky (one large request). If the user requires a large volume of data to complete a task, consider retrieving just what is required for display and to get started, then incrementally retrieve the additional data on a background thread or as the user requires it (data paging and UI virtualization are examples of this approach). Consider using larger, chunky calls when the user does not have to wait for the call to complete.
Composition
Consider whether your application will be easier to develop and maintain if the presentation layer uses independent modules and views that are composed at run time. UI composition patterns support the creation of views and the presentation layout at run time. 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. Consider the following guidelines when designing your UI composition strategy:
Avoid dependencies between components. For example, use abstraction patterns when possible to avoid issues with maintainability. Consider patterns that support run-time dependency injection.
Consider creating templates with placeholders. For example, use the Template View pattern to compose dynamic Web pages in order to ensure reuse and consistency.
Consider composing views from reusable modular parts. For example, use the Composite View pattern to build a view from modular, atomic component parts. Consider decoupling for your application by using separate modules that can be added easily.
Be cautious when using layouts generated dynamically at run time, which can be difficult to load and maintain. Investigate patterns and third-party libraries that support dynamic layout and injection of views and presentation at runtime.
When communicating between presentation components, consider using loosely coupled communication patterns such as Publish/Subscribe. This will lower the coupling between the components and improve testability and flexibility.
Exception Management
Design a centralized exception management mechanism for your application that catches and manages unexpected exceptions (exceptions that you cannot recover from locally) in a consistent way. Pay particular attention to exceptions that propagate across layer or tier boundaries, as well as exceptions that cross trust boundaries. Consider the following guidelines when designing your exception management strategy:
Provide user friendly error messages to notify users of errors in the application, but ensure that you avoid exposing sensitive data in error pages, error messages, log files, and audit files. Attempt to leave the application in a consistent state if possible, or consider terminating it if this is not possible.
Ensure that you catch exceptions that will not be caught elsewhere (such as in a global error handler), and clean up resources and state after an exception occurs. A global exception handler that displays a global error page or an error message is useful for all unhandled exceptions. Unhandled exceptions generally likely indicate that the system is in an inconsistent state and may need to be gracefully shut down.
Differentiate between system exceptions and business errors. In the case of business errors, display a user friendly error message and allow the user to retry the operation. In the case of system exceptions, check to see if an issue such as a service or database failure caused the exception, display a user friendly error message, and log the error message to assist in troubleshooting.
Only catch exceptions that you can handle, and avoid the use of custom exceptions when not necessary. Do not use exceptions to control application logic flow.
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 to hide application complexity. Consider the following guidelines when designing your navigation strategy:
Design toolbars and menus to help users find functionality provided by the UI.
Consider using wizards to implement navigation between forms in a predictable way, and determine how you will preserve navigation state between sessions if this is necessary.
Avoid duplication of logic for navigation event handlers, and avoid hard-coding navigation paths where possible. Consider using the Command pattern to handle common actions from multiple sources.
*********
User Experience(Удобство Использования)
При разработке пользовательского интерфейса необходимо учитывать:
Избегать построения перегруженных и сложных интерфейсов. Предоставлять простой и ясный порядок дествий для выполнения каждого ключевого сценария пользователя and consider using colors and noninvasive animations to draw the user's attention to important changes in the UI, such as state changes.
Provide helpful and informative error messages, without exposing sensitive data.
For actions that might take longer to complete, try to avoid blocking the user. At a minimum, provide feedback on the progress of the action, and consider if the user should be able to cancel the process.
Consider empowering the user by providing flexibility and customization of the UI through configuration and, where appropriate, personalization.
Consider how you will support localization and globalization, even if this is not a primary requirement in the initial design. Attempting to add support for localization and globalization once the design is complete can involve a great deal of rework and refactoring.
User Interface
Design a suitable user interface to support your data input and data validation requirements. For maximum usability, follow the established guidelines defined by your organization, and the many established industry usability guidelines that are based on years of user research into input design and mechanisms. When choosing a layout strategy for your user interface, 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. Consider the following guidelines when designing your user interface:
Consider using a Separated Presentation pattern such as MVP to separate the layout design from interface processing. Use templates to provide a common look and feel to all of the UI screens, and maintain a common look and feel for all elements of your UI to maximize accessibility and ease of use. Avoid over complex layouts.
Consider using forms-based input controls for data collection tasks, a document-based input mechanism for collecting more free form input such as text or drawing documents, or a wizard-based approach for more sequenced or workflow driven data collection tasks.
Avoid using hard-coded strings, and using external resources for text and layout information (for example, to support right-to-left languages), especially if your application will be localized
Consider accessibility in your design. You should consider users with disabilities when designing your input strategy; for example, implement text-to-speech software for blind users, or enlarge text and images for users with poor sight. Support keyboard-only scenarios where possible for users who cannot manipulate a pointing device.
Take into account different screen sizes and resolutions, and different device and input types such as mobile devices, touch screens, and pen and ink—enabled devices. For example, with touch screen input you will typically use larger buttons with more spacing between them than you would in a UI designed only for mouse and keyboard input. When building a Web application, consider using Cascading Style Sheets (CSS) for layout. This will improve rendering performance and maintainability.
Validation
Designing an effective input and data validation strategy is critical for the security and correct operation of your application. Determine the validation rules for user input as well as for business rules that exist in the presentation layer. Consider the following guidelines when designing your input and data validation strategy:
Input validation should be handled by the presentation layer, whilst business rule validation should be handled by the business layer. However, if your business and presentation layers are physically separated, business rule validation logic should be mirrored in the presentation layer to improve usability and responsiveness. This can be achieved using meta-data or by using common validation rule components in both layers.
Design your validation strategy to constrain, reject, and sanitize malicious input. Investigate design patterns and third party libraries that can assist in implementing validation. Identify business rules that are appropriate for validation, such as transaction limits, and implement comprehensive validation to ensure that these rules are not compromised.
Ensure that you correctly handle validation errors, and avoid exposing sensitive information in error messages. In addition, ensure that you log validation failures to assist in the detection of malicious activity.
Design patterns
Key patterns for the presentation layer are organized by categories as detailed in the following table. Consider using these patterns when making design decisions for each category.
Category
Relevant patterns

Caching
Cache Dependency. Use external information to determine the state of data stored in a cache.
Page Cache. Improve the response time for dynamic Web pages that are accessed frequently, but change less often and consume a large amount of system resources to construct.

Composition and Layout
Composite View. Combine individual views into a composite representation.
Presentation Model (Model-View-ViewModel) pattern. A variation of Model-View-Controller (MVC) tailored for modern UI development platforms where the View is the responsibility of a designer rather than a classic developer.
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 into 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.

Exception Management
Exception Shielding. Prevent a service from exposing information about its internal implementation when an exception occurs.

Navigation
Application Controller. A single point for handling screen navigation.
Front Controller. A Web only pattern that consolidates request handling by channeling all requests through a single handler object, which can be modified at run time with decorators.
Page Controller. Accept input from the request and handle it for a specific page or action on a Web site.
Command. Encapsulate request processing in a separate command object with a common execution interface.

User Experience
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.
Chain of Responsibility. Avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request.