Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
ООП / ООП / ры_приложений_полная_книга.pdf
Скачиваний:
500
Добавлен:
18.02.2017
Размер:
7.08 Mб
Скачать

Выявите ошибки и исключения, которые могут возникать в приложении, и определите, для которых из них требуется только уведомление пользователя. Обычно для таких ошибок, как ошибки валидации, реализуется только локальное уведомление пользователя. Однако такие ошибки, как неоднократная неудачная попытка регистрации или выявление злонамеренных данных, должны протоколироваться, и администраторы должны получать уведомления о них. Все исключения, возникающие в ходе выполнения, и сбои приложения должны протоколироваться, и, если это необходимо, администраторы должны уведомляться о них.

Выработайте общую стратегию обработки исключений. Она может включать такие действия, как заключение исключений в другие исключения, характерные для приложения или собственные, которые будут содержать дополнительные данные, используемые при разрешении сбоев, или замена исключений для предотвращения раскрытия конфиденциальных данных. Также реализуйте механизм выявления и протоколирования необрабатываемых исключений. В реализации этих задач может быть полезной инфраструктура управления исключениями, такая как разработанная группой patterns & practices Enterprise Library.

Примите решение о том, как будет реализовано хранение данных исключений, их передача в другие слои приложения в случае необходимости, и как будет выполняться уведомление администраторов. Используйте инструменты или инфраструктуру мониторинга, которая может собирать сведения о событиях с локального компьютера и предоставлять отчет о состоянии приложения администраторам.

Обеспечьте очистку данных исключений, предоставляемых пользователям, чтобы предотвратить возможность отображения или сохранения в файлах журнала или аудита конфиденциальных данных. В случае необходимости шифруйте данные и передавайте исключения и ошибки на другие уровни приложения по безопасным каналам.

Перехватывайте только те исключения, которые можете обработать. Например, перехватывайте исключения преобразования данных, которые могут возникать при попытках преобразования значений null. Не используйте исключения для управления бизнес-логикой.

Более подробно обработка исключений рассматривается в главе 17, «Сквозная функциональность».

Удобство и простота обслуживания

Для всех приложений и компонентов исключительно важно максимально сократить затраты и упростить обслуживание. Необходимо реализовать механизмы, снижающие расходы на обслуживание, например, использовать шаблоны проектирования, обеспечивающие разделение функциональных областей и слабое связывание компонентов. Насыщенные клиентские приложения обычно располагаются на удаленных клиентских компьютерах и, следовательно, их сложнее обслуживать, чем установленные на сервере приложениями. Поэтому необходимо также учесть такие факторы, как развертывание, обновление,

исправление и управление версиями. При проектировании стратегии обслуживания руководствуйтесь следующими рекомендациями:

Реализуйте подходящий механизм обновления приложения и его компонентов вручную и/или автоматически. Необходимо учесть аспекты управления версиями, чтобы гарантировать непротиворечивость и совместимость версий всех используемых им компонентов.

Исходя из среды, в которой предполагается использовать приложение, выбирайте соответствующий подход к развертыванию. Например, для открыто доступных приложений может потребоваться программа установки, а для развертывания приложений в закрытой среде можно будет воспользоваться системными инструментами, такими как Microsoft System Center.

Проектируйте для приложения слабо связанные и по возможности взаимозаменяемые компоненты. Это позволит заменять отдельные компоненты в зависимости от требований, сценариев времени выполнения и требований или предпочтений конкретных пользователей. Также обеспечьте минимальные зависимости между компонентами и слоями, чтобы иметь возможность использовать приложение или отдельные слои и компоненты в различных сценариях.

Реализуйте для приложения соответствующее протоколирование и аудит. Эти данных будут полезны администраторам и разработчикам при отладке приложения и решении проблем, возникающих во время выполнения.

Более подробно вопросы удобства и простоты обслуживания обсуждаются в главе 16, «Показатели качества».

Слой представления

Слой представления – это часть приложения, которую видит пользователь и с которой он взаимодействует, поэтому этот слой должен удовлетворять многим требованиям. К ним относятся общие факторы, такие как удобство использования, производительность, дизайн и возможность взаимодействия с пользователем. Неудовлетворительное взаимодействие с пользователем может иметь чрезвычайно негативные последствия для приложения, удачного во всех остальных отношениях. При проектировании приложения важно с самого начала обеспечить привлекательный и интуитивный интерфейс, поскольку на взаимодействие с пользователем оказывают влияние многие аспекты архитектуры приложения. При проектировании представления приложения руководствуйтесь следующими рекомендациями:

Продумайте, как отделить логику взаимодействия с пользователем от UI, а также от данных, с которыми работает пользователь. Возможно, для этого подойдет шаблон Separated Presentation. Это упростит обновление частей приложения, позволит разработчикам и дизайнерам работать над компонентами независимо друг от друга и улучшит тестируемость.

Реализуйте гибкие и легко обновляемые стратегии и механизмы управления и навигации. Используйте в приложении популярные шаблоны проектирования, такие

как Command, Publish/Subscribe и Observer, для отделения команд и навигации от компонентов, это позволит улучшить тестируемость.

Максимально используйте возможности привязки данных, особенно при отображении данных в виде таблиц или множества строк. Это сократит объем необходимого кода и количество ошибок, упростит разработку. Также можно реализовать автоматическую синхронизацию данных в различных представлениях или формах. Используйте двустороннюю привязку, если необходимо обеспечить пользователю возможность обновления данных.

Продумайте, как будут отображаться документы в интерфейсе в стиле Office либо при отображении содержимого документов или HTML в других элементах UI. Обеспечьте защиту пользователя от недействительного или злонамеренного содержимого, которое может находиться в документах.

Обеспечьте интернационализацию UI с последующей локализацией для всех географических или культурных сценариев, в которых оно может использоваться. Сюда относятся возможности изменения языка, направления текста и компоновки содержимого на основании конфигурации или автоматического определения культурной принадлежности пользователя. Также обеспечьте необходимые специальные возможности доступа и навигацию.

Вопросы проектирования слоя представления подробно рассматриваются в главе 6, «Рекомендации по проектированию слоя представления».

Управление состоянием

Управление состоянием занимается вопросами сохранения данных, представляющих состояние компонента, операции или этапа процесса. Данные состояния могут включать пользовательские настройки, конфигурационные данные, данные рабочего процесса, значения бизнес-правил и данные, отображаемые в UI. Приложение должно иметь возможность сохранять эти данные, иметь к ним доступ в случае необходимости и обрабатывать конфликты, перезапуски и изменения состояния подключения. При проектировании стратегии управления состоянием руководствуйтесь следующими рекомендациями:

Определите, какие данные состояния должно сохранять приложение, а также оцените их размер, частоту изменения и затраты или издержки на обработку восстановления или повторного извлечения этих данных; также выберите механизм управления состоянием, который может обеспечить соответствующую поддержку этому.

При наличии больших объемов данных состояния храните их локально на диске. Если приложению необходимо, чтобы некоторые данные были доступны при его запуске, используйте механизм постоянного хранения, такой как изолированное хранилище или файл на жестком диске.

При хранении конфиденциальных данных обеспечьте соответствующий уровень их защиты через использование шифрования и/или цифровых подписей.

Примите решение о том, насколько детализированными должны быть сохраняемые данные состояния. Например, определите данные состояния, которые относятся ко всем пользователям приложения, и данные, относящиеся только к определенным пользователям или ролям.

Рабочий процесс

Некоторые насыщенные клиентские приложения требуют реализации поддержки потока представления или рабочего процесса для обеспечения многошаговых операций или элементов UI в стиле мастера. Эти возможности могут быть реализованы с применением отдельных компонентов или специальных решений, либо можно использовать преимущества такой технологии, как Windows Workflow Foundation (WF). При проектировании рабочего процесса руководствуйтесь следующими рекомендациями:

Используйте рабочий процесс в бизнес-компонентах для операций, включающих многошаговые или длительные процессы. Реализуйте задачи рабочего процесса и потока представления в отдельных компонентах. Это сокращает количество зависимостей и упрощает замену компонентов в случае изменения требований.

Для простых рабочих процессов и потоков представления обычно достаточно собственного кода, основанного на общеизвестных шаблонах, таких Use Case Controller (Контроллер вариантов использования) и ViewFlow (Поток представления). Для более сложных случаев используйте подсистему управления рабочим процессом, такую как

WF.

Продумайте стратегию перехвата, управления и отображения ошибок в рабочих процессах. Также примите решение об обработке частично завершенных задач и о том, будет ли возможно восстановление и продолжение выполнения задачи после сбоя либо придется перезапускать процесс.

Более подробно компоненты рабочего процесса рассматриваются в главе 14, «Проектирование компонентов рабочего процесса».

Вопросы безопасности

Безопасность охватывает широкий диапазон факторов и имеет решающее значение для всех типов приложений. Проектирование и реализация насыщенных клиентских приложений должны вестись с обязательным учетом вопросов безопасности, а там где эти приложения выступают в роли слоя представления для бизнес-приложений, они должны участвовать в обеспечении безопасности других слоев приложения. Безопасность касается множества аспектов, включая защиту конфиденциальных данных, аутентификацию и авторизацию пользователей, защиту от атак злонамеренного кода и пользователей, аудит и протоколирование событий и действий пользователей. При проектировании стратегии обеспечения безопасности руководствуйтесь следующими рекомендациями:

Выберите подходящую технологию и подход к аутентификации пользователей, включая поддержку множества пользователей для одного экземпляра насыщенного

Соседние файлы в папке ООП