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

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

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

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

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