базы данных, а используйте специализированные объекты необходимые приложению. Реализуйте кэширование в памяти с помощью Microsoft Velocity.

Не кэшируйте часто изменяющиеся данные и незашифрованные конфиденциальные данные.

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

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

Более подробно разработка стратегии кэширования рассматривается в разделе «Этапы проектирования стратегии кэширования» далее в этой главе.

Сетевое взаимодействие

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

Используйте взаимодействие посредством обмена сообщениями при пересечении физических границ или границ процесса; и взаимодействие объектов внутри процесса (при пересечении только логических границ). Для сокращения числа циклов запрос-ответ и повышения производительности взаимодействия через физические границы и границы процесса, проектируйте обобщенные интерфейсы, взаимодействующие не так часто, но передающие большие объемы данных при каждом взаимодействии. Тем не мене, там где это необходимо, предоставляйте детализированные интерфейсы, которые будут использоваться вызовами внутри процесса, и заключайте эти вызовы в обобщенный фасад, который будет использоваться процессами, выполняющими доступ к нему через физические границы или границы процессов.

Если порядок получения сообщений не имеет значения, и сообщения не зависят друг от друга, используйте асинхронное взаимодействие. Это поможет избежать блокировки обработки или потоков UI.

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

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

гарантий надежности (такие как соглашения на уровне сервиса) и механизм аутентификации.

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

Более подробно проектирование стратегии взаимодействия рассматривается в главе 18, «Взаимодействие и обмен сообщениями».

Управление конфигурацией

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

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

Примите решение о том, будут ли сведения о конфигурации храниться централизованно и загружаться или применяться к пользователям при запуске (например, через Active Directory Group Policy1). Продумайте, как обеспечите ограничение доступа к сведениям о конфигурации. Используйте менее привилегированный процесс и учетные записи сервиса и шифруйте конфиденциальные данные в хранилище конфигурации.

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

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

Предоставьте отдельный административный UI для редактирования конфигурационных данных.

1 Групповая политика Active Directory (прим. переводчика).

Управление исключениями

Проектирование эффективной стратегии управления исключениями имеет большое значение с точки зрения обеспечения безопасности и надежности приложения. Неправильный выбор стратегии очень усложнит диагностирование и решение проблем приложения, сделает его уязвимым для атак типа отказ в обслуживании (DoS), а также может привести к разглашению конфиденциальных и важных сведений. Формирование и обработка исключений является ресурсоемким процессом, поэтому важно, чтобы при проектировании были также учтены вопросы производительности. Хорошим подходом является проектирование централизованного механизма управления исключениями для приложения и предоставление точек доступа к системе управления исключениями (таких как события WMI) для обеспечения поддержки систем мониторинга уровня предприятия, таких как Microsoft System Center. При проектировании стратегии управления исключениями руководствуйтесь следующими рекомендациями:

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

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

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

Более подробно проектирование стратегии управления исключениями рассматривается в разделе «Этапы проектирования стратегии управления исключениями» далее в этой главе.

Протоколирование и инструментирование

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

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

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

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

Сделайте свои приемники журнала, или слушатели трассировки, настраиваемыми, чтобы обеспечить возможность их изменения во время выполнения соответственно требованиям инфраструктуры развертывания. В реализации протоколирования и инструментирования в приложении очень помогут такие библиотеки, как Enterprise Library группы patterns & practices. Среди популярных библиотек можно также упомянуть NLog и log4net (больше информации по этому вопросу можно найти в разделе Дополнительные источники в конце данной главы)

Более подробно протоколирование и инструментирование рассматриваются в разделе «Этапы проектирования стратегии управления исключениями» далее в этой главе.

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

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

Сохраняйте минимальный объем данных состояния.