Сергей Зыков - Основы проектирования корпоративных систем

Следующий блок связан с обработкой исключений. Он называется Exception Handling Application Block. Известно, что на стандартной платформе. NET, в. NET Framework, существует специальное пространство имен, которое называется System Exception. Внутри этого пространства существуют различные классы для обработки разных видов исключений – арифметических ошибок, ошибок, связанных с доступом к данным, и т. д. Здесь этот принцип обобщается на уровень корпоративных приложений.

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

Что очень важно, обработка исключений становится политикой, можно задавать и конфигурировать на основе этого блока политики обработки исключений. По сути, существуют классы, которые отвечают за исключения, за обработку конкретного вида исключений и за действия, связанные с обработкой того или иного рода исключений. Здесь удается определить политики обработки исключений и обеспечить связь между определенным классом исключений, которые существуют в иерархии классов System Exception или в другой иерархии классов, связанной с библиотеками Enterprise Library, и определить стандартный сценарий действий по обработке этих исключений. Таким образом, обеспечивается последовательный интерфейс обработки исключений, создание политик обработки исключений, поддерживается стратегия обработки исключений на всех архитектурных уровнях корпоративных приложений, а не только на уровне интерфейса, который обеспечивают прикладные сервисы. При этом политики обработки исключений могут поддерживаться, создаваться на разных уровнях администрирования, как для администраторов, так и для разработчиков. Эти политики задаются в форме правил.

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

Следующий блок связан с ведением системных журналов, протоколов. Он называется Login Application Block. Важно отметить, что существует стандартный журнал – Event Log, в который записываются все системные события ОС Windows, связанные как с предупреждениями, так и ошибками. Этот механизм позволяет осуществлять запись прямо на уровне системного журнала, а также передавать сведения о системных событиях, ошибках по электронной почте, записывать данные в базу данных, в очередь сообщений, в текстовый файл, создавать события, используя механизм из ядра, который называется Instrumentation, а также использовать точки расширения этого функционального блока, которые имеются у него, как у прочих функциональных блоков Enterprise Library.

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

Еще один важный блок связан с выполнением стандартных операций внутри приложения, он называется Policy Injection Application Block. Здесь можно задавать правила, предусловия, постусловия для каждой из стандартных операций. Это регистрация данных, кэширование, обработка ошибок, коррекция или проверка достоверности информации внутри приложения. При этом работа ведется на уровне объектов, и для каждого конкретного объекта приложения можно указать как предусловия, так и постусловия, характерные особенности, в том числе имя сборки, к которой принадлежит объект, имя пространства имен, имя, тип и атрибуты объекта. При этом взаимодействие между объектами приложений обеспечивается посредством традиционных клиент-серверных приложений с использованием клиента и прокси, о которых говорилось в предыдущих главах. Этот блок создает для каждого вновь сконфигурированного класса прокси, который инкапсулирует правила, применяемые к явно назначенным и используемым атрибутам. Существует возможность присоединения средств обмена данными и обработчиков таких средств каждому методу для каждого прокси. И для каждого экземпляра целевого объекта приложения можно создать соответствующие методы и свойства и управлять этими методами и свойствами. То есть политики регламентирования правил, управления пред– и постусловиями, выполнения операций для этих объектов могут осуществляться на разных уровнях, как на уровне приложения, так и на уровне корпорации в целом.