Выработайте стратегию передачи журналов клиента на сервер для обработки. При диагностике проблем конкретного клиентского компьютера может возникнуть необходимость в объединении журналов разных пользователей этого компьютера. Ведите отдельные журналы для каждого пользователя, а не для компьютера в целом, поскольку на каждом клиентском компьютере могут работать несколько пользователей.
При использовании изолированного хранилища для протоколирования предусмотрите предельный размер хранилища и необходимость направления запроса пользователю об увеличении объема хранилища в случае необходимости.
Обеспечьте протоколирование критических ошибок и предусмотрите включение протоколирования и передачу журналов на сервер при возникновении исключений.
Мультимедиа и графика
Реализации RIA обеспечивают намного более насыщенный интерфейс пользователя и лучшую производительность, чем обычные Веб-приложений. Изучите и примените возможности работы с мультимедиа используемой платформы RIA. Не забывайте, что некоторые возможности платформы RIA могут быть недоступны в автономном проигрывателе мультимедиа. При проектировании возможностей работы с мультимедиа и графикой руководствуйтесь следующими рекомендациями:
При проектировании обеспечьте воспроизведение потокового мультимедиа и видео в браузере без использования специального проигрывателя. Рекомендуется использовать адаптивную потоковую передачу в сочетании с RIA-клиентами, это позволит корректно и плавно обрабатывать проблемы, возникающие из-за изменяющейся полосы пропускания.
Для повышения производительности позиционируйте объекты мультимедиа с привязкой к целочисленным значениям пикселов и представляйте их в исходном размере. Для обеспечения лучшей производительности отрисовки используйте встроенные средства обработки векторной графики.
Для особо насыщенного графикой приложения выясните, обеспечивает ли реализация RIA аппаратное ускорение. Если нет, определите минимально допустимую скорость отрисовки. Выработайте план сокращения нагрузки на графический процессор в случае падения скорости ниже допустимого минимума.
Принимайте во внимание размер областей отрисовки. Перерисовывайте только те части области, которые на самом деле меняются. Сокращайте области перекрытия, когда в них нет необходимости, для снижения эффекта наложения. Используйте методы профилирования и отладки (например, параметр «EnableRedrawRegions = true» в Silverlight) для выявления перерисованных областей. Обратите внимание, что определенные эффекты, такие как размытие, могут обусловливать перерисовку каждого пиксела области. Безоконные прозрачные элементы управления могут также приводить к непредусмотренным перерисовкам и наложению.
Приложения для мобильных устройств
Реализации RIA обеспечивают намного более насыщенные пользовательские интерфейсы, чем обычные мобильные приложения. Используйте встроенные возможности работы с мультимедиа той платформы RIA, с которой работаете. При проектировании приложений для работы с мультимедиа и графикой на мобильных устройствах руководствуйтесь следующими рекомендациями:
Если RIA должно устанавливаться на мобильном клиенте, выясните, доступна ли реализация подключаемого модуля RIA для устройства, которое предполагается поддерживать. Также примите во внимание, что функциональность подключаемого модуля RIA для мобильных устройств может быть ограничена по сравнению с немобильными платформами.
Старайтесь использовать один или подобный код, а потом уже в случае необходимости создавайте версии кода для конкретных устройств.
Обеспечьте, чтобы компоновка и реализация UI подходили для небольших экранов мобильных устройств. RIA-приложения работают на мобильных устройствах, но предусмотрите разный код компоновки для каждого типа устройств, это поможет обеспечить корректное отображение UI на экранах разных размеров при проектировании для Windows Mobile.
Более подробно реализация приложений для мобильных устройств рассматривается в главе 24, «Проектирование мобильных приложений».
Портируемость
Одно из основных преимуществ RIA – портируемость компилированного кода между разными браузерами, операционными системами и платформами. Кроме того, использование одного и того же или подобного исходного кода сокращает время и затраты на разработку и обслуживание, обеспечивая при этом независимость от платформы. При проектировании с обеспечением портируемости руководствуйтесь следующими рекомендациями:
Полностью используйте встроенные библиотеки кода RIA и проектируйте так, чтобы «однажды написанное выполнялось везде», но будьте готовы создавать различные версии кода в случаях, когда это требуется из-за общей сложности проекта или необходимости принятия компромиссов по обеспечиваемой функциональности.
Выбирая между RIA и Веб-приложением, не забывайте, что из-за различий браузеров для Веб-приложения потребуется всестороннее тестирование кода ASP.NET и JavaScript. В случае с RIA-приложением вопросами совместимости с различными платформами занимается создатель подключаемого модуля, а не разработчик приложения. Это существенно сокращает затраты на тестирование для каждого сочетания платформы и браузера.
Если RIA планируется выполнять на множестве платформ, не используйте возможности, доступные только на одной платформе, например, Windows
Integrated Authentication. Основывайте решение на портируемых процедурах и функциях RIA, которые доступны на многих клиентах.
При создании насыщенных клиентских или RIA-приложений обратите внимание на языки и среды разработки, такие как Composite Client Application Guidance группы patterns & practices, предлагающие решения, подходящие для обеих платформ. Подробнее эти вопросы рассматриваются в статье «Composite Client Application Guidance» по адресу http://msdn.microsoft.com/en-us/library/cc707819.aspx.
Представление
Поскольку, как правило, RIA-приложения ориентированы на выполнение в браузере, лучше всего они работают при наличии всего одного центрального интерфейса. Для многостраничных приложений требуются механизмы связывания страниц. При проектировании представления руководствуйтесь следующими рекомендациями:
Используйте шаблоны Separated Presentation для разделения визуального представления от логики представления приложения.
Максимально используйте преимущества привязки данных для отображения данных, особенно для табличного и многострокового представления данных. Это сократит объем требуемого кода, упростит разработку и уменьшит количество ошибок в коде. Также это может обеспечить автоматическую синхронизацию данных в разных представлениях или формах. Используйте двустороннюю привязку там, где пользователь должен иметь возможность обновлять данные.
Для многостраничных UI используйте методы внешнего связывания. Это обеспечит уникальную идентификацию и возможность перехода к конкретным страницам приложения.
Перехватывайте события кнопок вперед и назад браузера. Это позволит избежать нечаянных переходов со страницы. Также рассмотрите возможность управления содержимым адресной строки браузера и списком истории для реализации навигации, как на обычной Веб-странице.
Более подробно реализация слоя представления рассматривается в главе 6, «Рекомендации по проектированию уровня представления».
Управление состоянием
Состояние приложения может храниться на клиенте в изолированном хранилище. Это удобно для локального сохранения или кэширования состояния между пользовательскими сеансами. Изолированное хранилище управляется не так, как кэш браузера. Приложения, сохраняющие данные в изолированном хранилище, должны либо удалять их напрямую, либо явно указывать пользователю о необходимости удалить эти данные. При проектировании стратегии управления состоянием руководствуйтесь следующими рекомендациями:
Определите, какие данные состояния должно сохранять приложение, оцените предполагаемый размер необходимого хранилища, частоту изменений, затраты на
обработку или издержки на повторное создание или повторное извлечение данных.
Чтобы сохранить состояние между сеансами, храните данные состояния на клиенте в изолированном хранилище. Состояние, необходимое для функционирования приложения, всегда должно сохраняться на сервере. Это также обеспечивает пользователям доступ к сохраненному состоянию при входе в систему с другого компьютера.
При проектировании обеспечьте возможность параллельного выполнения множества сеансов, потому что предотвратить одновременный запуск множества экземпляров невозможно. Обеспечьте в стратегии управления состоянием либо обработку параллелизма, либо механизм, выявляющий и не допускающий нарушение состояния приложения в результате выполнения множества сеансов.
Валидация
Валидация должна осуществляться в коде на клиенте или через сервисы, расположенные на сервере. Если на клиенте требуется нечто большее, чем обычная проверка, выносите логику валидации в отдельную загружаемую сборку. Это упрощает обслуживание правил. При проектировании стратегии валидации руководствуйтесь следующими рекомендациями:
Используйте валидацию на стороне клиента, чтобы обеспечить лучшее взаимодействие с пользователем, но из соображений безопасности всегда выполняйте проверку и на сервере. Вообще исходите из предположения о том, что все поступающие от клиента данные являются злонамеренными. Сервер должен перепроверять все передаваемые на него данные. Обеспечивайте проверку ввода со всех источников, таких как строки запроса, cookies и элементы управления HTML.
Проектируйте механизмы валидации, обеспечивающие ограничение, отклонение и очистку данных. Проверяйте длину, диапазон, формат и тип вводимых данных. Обозначьте границы доверия на сервере и проверяйте все данные, пересекающие их.
Храните правила валидации клиента в изолированном хранилище. Для правил, требующих доступа к ресурсам сервера, продумайте, не будет ли более эффективным использовать отдельный сервис, выполняющий проверку на сервере.
При наличии на стороне клиента большого объема кода валидации, который может меняться, рассмотрите возможность его размещения в отдельном загружаемом модуле. Это упростит его замену без необходимости повторной загрузки всего RIAприложения.
Более подробно методики валидации обсуждаются в главе 17, «Сквозная функциональность».