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

Авторизация

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

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

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

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

Не смешивайте код авторизации и код обработки бизнес-задач в одном компоненте.

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

Кэширование

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

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

Рассмотрите возможность кэширования данных в бизнес-слое в готовом к использованию виде.

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

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

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

Связывание и связность

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

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

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

Если динамическое поведение не требует слабого связывания, обеспечивайте тесное связывание в рамках бизнес-слоя при проектировании.

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

Использование основанных на обмене сообщениями механизмов доступа к компонентам бизнес-слоя обеспечивает снижение связанности и возможность размещения их на других уровнях в случае необходимости.

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

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

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

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

Убедитесь, что перехватываете исключения, которые не будут перехвачены гделибо в другом месте (например, глобальном обработчике ошибок), и очищайте ресурсы и состояние после возникновения исключения.

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

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

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

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

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

Обеспечьте централизацию протоколирования, аудита и инструментирования для бизнес-слоя. Для реализации функциональности обработки исключений и протоколирования используйте библиотеку Enterprise Library от patterns & practices или решения сторонних производителей, такие как Сервисы протоколирования

Apache (Apache Logging Services) «log4Net» или сервис «NLog» Ярослава Ковальского (Jarosław Kowalski).

Включите в компоненты бизнес-слоя инструментарий для критических событий системы и бизнес-процесса.

Не храните конфиденциальные бизнес-данные в файлах журнала.

Обеспечьте, чтобы сбой протоколирования не оказывал влияния на нормальную функциональность бизнес-слоя.

Рассмотрите возможность аудита и протоколирования всех эпизодов доступа к функциям бизнес-слоя.

Валидация

Проектирование эффективного механизма валидации для бизнес-слоя имеет большое значение с точки зрения обеспечения удобства и простоты использования и надежности приложения, в противном случае, оно может остаться открытым для несогласованности данных и нарушений бизнес-правил, а также обеспечивать неудовлетворительный уровень взаимодействия с пользователем. Кроме того, приложение может оказаться уязвимым к таким угрозам безопасности, как межсайтовые атаки внедрением сценариев (cross-site scripting, XSS), атаки типа внедрение SQL-кода, переполнение буфера и другие типы атак посредством входных данных. Четкого и исчерпывающего определения действительного или злонамеренного ввода нет. Возможные риски, обуславливаемые злонамеренным вводом, зависят также от того, как приложение использует ввод. При проектировании стратегии валидации руководствуйтесь следующими рекомендациями:

Проверяйте все вводимые данные и параметры методов в бизнес-слое, даже если проверка ввода выполняется в слое представления.

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

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