Читать книгу - "Интернет-журнал "Домашняя лаборатория", 2007 №6 - Усманов"

• PrepareToFire

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

♦ [in] Идентификатор событийного интерфейса

♦ [in] Метод событийного интерфейса

Эти два параметра определяют тип события, рассылку уведомлений о котором инициирует издатель,

♦ [out] Указатель на интерфейс IFiringControl

Это интерфейс реализован в системе. Фильтр использует его для вызова метода IFiringControl::FireSubscription. Этот метод принимает В качестве единственного (входного) параметра указатель на интерфейс IEventSubscription объекта-подписки, которому следует отправить уведомление о событии. Именно здесь фильтр может определить подписчиков и порядок рассылки им уведомлений.

Фильтр на стороне подписчика

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

Среди свойств объекта-подписки имеется свойство FilterCriteria. Это свойство администратор может задавать при регистрации подписки с помощью Component Services. Критерий фильтрации задается логическим выражением, содержащим параметры событийного метода, операторы отношений, константы, логические операторы и скобки. Таким образом, задав критерий фильтрации, администратор устанавливает так называемое параметрическую фильтрацию, результат которой определяется значениями параметров вызываемого метода событийного интерфейса. Данная фильтрация выполняется естественно после фильтрации, выполненной на стороне издателя. В связи с тем, что критерий параметрической фильтрации хранится в подписке на той же машине, где зарегистрирован событийный класс, никакие излишние вызовы на машину, где обычно активируется подписчик, не выполняются. Естественно, и сам подписчик активируется если только направляемое ему уведомление преодолело параметрический фильтр.

.NET Framework от Microsoft

Введение

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

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

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

Ранее в данном курсе упомянутые вопросы уже рассматривались при рассмотрении технологии COM (СОМ+). Новая технология (.NET) во многом основана на идеях СОМ. Пришло время, когда все программисты, работающие на платформе Windows, должны будут познакомиться с этими идеями.

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

В .NET о компонентах говорится особо. Имеется пространство имен system. componentModel, в котором определяются классы и интерфейсы, поддерживающие некоторую модель компонентного программирования. В рамках этой модели компонентами называются классы (производные от некоторых специальных классов или реализующие некоторые специальные интерфейсы), используемые прежде всего при разработке пользовательского интерфейса. Но уже в СОМ подход к понятию компонента был значительно шире. В данном курсе понятие компонента не определяется строго. Неформально понятие компонент связывается с технологией, ориентированной на распределенное программирование распределенных систем. Базы данных, интерфейс пользователя — это важные темы, но они не относятся исключительно к распределенным системам и, в связи с этим, не затрагиваются в данном курсе.

Можно выделить две компонентные модели, поддерживаемые технологией .NET. Во-первых, это уровень CLR (Common Language Runtime) — основа всей технологии .NET. Данная модель наиболее близка к СОМ. Во-вторых, это очень популярная сегодня модель XML Web-сервисов, в рамках которой возможно взаимодействие программ, исполняющихся на разных платформах при условии, что взаимодействующие программы понимают протокол SOAP.

Здесь мы будем говорить только о первой модели. Это представляется вполне естественным при переходе от таких тем как СОМ и СОМ+. И изложение будет основано на сопоставлении компонентной модели СОМ и модели, поддерживаемой в CLR.

Интерфейсы

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

В СОМ и в СОМ+ мы видим огромное множество интерфейсов, совокупность которых можно рассматривать как некоторое компонентно — ориентированное расширение базового языка программирования (например, C++). Стоит отметить, что изучать эти интерфейсы весьма не просто в силу их многочисленности и отсутствия единой систематизирующей структуры.

Роль интерфейсов в .NET резко сокращена. На взгляд автора, теперь интерфейсы прежде всего служат для расширения множества типов, приписанных данному классу. В отличие от СОМ, где не было наследования реализации, в .NET класс может наследовать одному классу (по умолчанию классу System.Object) и любому числу интерфейсов, которые не имеют реализации и не наследуют корневому классу System.Object.

Относительное снижение значимости интерфейсов в .NET по сравнению с СОМ в .NET компенсируется следующим:

• Клиент больше не изолируется от компонента

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

• Многие интерфейсы более не нужны

Многие интерфейсы, играющие важную роль в СОМ, более не нужны в .NET. С помощью представленного ниже примера будет объяснено, почему, например, стал не нужен базовый интерфейс для СОМ — IUnknown.