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

Шаг 8 – Принятие решение об обработке необрабатываемых исключений

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

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

Реализуйте стратегию управления исключениями, протоколирования и уведомления с помощью Exception Handling Application Block (Блок обработки исключений) и Logging Application Block (Блок протоколирования), созданных группой patterns & practices. Exception Handling Application Block поддерживает ряд вариантов обработки исключений. Logging Application Block может принимать, форматировать и отправлять сообщения и уведомления журнала в различные журналы и другие точки назначения. Более подробно эти вопросы рассматриваются в приложении F, «Enterprise Library от patterns & practices».

Этапы проектирования стратегии валидации ввода и данных

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

Шаг 1 – Определение границ доверия

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