Читать онлайн «C# для профессионалов. Том II». Страница 57

Как можно было уже догадаться, утилиты TlbExp и RegAsm были созданы для работы в тесном взаимодействии. RegAsm используется для регистрации компонента .NET в службах COM, а затем TlbExp — для экспорта библиотеки типов COM клиенту и ссылки на нее из языков не принадлежащих .NET.

Мы рассказали о взаимодействии между компонентами COM и .NET. Теперь поговорим о другом виде — о взаимодействии между кодом .NET и так называемом неуправляемом коде. Его обеспечивает технология, называемая службами вызова платформы, или, кратко, PInvoke.

Первое, о чем необходимо знать, — термины неуправляемый и ненадежный не являются синонимами.

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

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

Службы вызова платформы позволяют коду .NET взаимодействовать не только с ненадежным кодом, но и с достоверно неуправляемым.

Хотя .NET может взаимодействовать с неуправляемым кодом в любой DLL, чаще всего он взаимодействует с кодом в DLL, составляющим базовую функциональность Windows API. Это включает user32.dll, gdi32.dll и kernel32.dll. Процесс представления функций из этих DLL для кода .NET должен быть знаком любому, кто использовал ключевое слово Declare для предоставления вызовов Win32 API для кода VB6:

[sysimport(dll="user32.dll")]

public static extern int MessageBoxA(int Modal, string Message, string Caption, int Options);

В приведенном примере с помощью оболочки .NET вызова осуществляется вызов Windows API, который выводит окно с сообщением. В атрибуте выше функции оболочки определяется DLL, которой функция в оболочке должна делегировать свою работу. Теперь клиент кода .NET может вызывать функцию оболочки для вызова функций API:

MessageBoxA(0, "PInvoke worked!", "PInvoke Example", 0);

Хотя здесь для функции оболочки задано такое же имя, как и для вызова Windows API, в который она отображается, можно задать для нее и другое имя, как делалось в примере выше. Изменим теперь имя "MessageBox" на имя, которое более точно определяет, как будет использоваться вызов API. Сделаем это, определяя дополнительное значение в атрибуте sysimport:

[sysimport (dll="ustr32.dll", name="MessageBoxA") ]

public static extern int ErrorMessage(int Modal, string Message, string Caption, int Options);

При переименовании вызова Windows API таким образом клиенты могут вызывать функцию с новым именем:

ErrorMessage(0, "PInvoke worked!", "PInvoke.Example", 0);

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

Хотя Microsoft сознательно откладывает вопрос взаимодействия платформ, многие люди подозревают, что оно уже на горизонте для платформы .NET. При взаимодействии платформ можно выполнить программу .NET на любой платформе — от Macintosh до Unix при условии, что платформ? обеспечена средой времени выполнения .NET. Однако при использовании PInvoke, код .NET соединяется с операционной системой Windows.

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

Как показывает эта глава, COM и .NET являются различными технологиями, которые способны работать совместно, если применяются соответствующие технологии. Используя утилиты взаимодействия, такие как TlbImp.exe, RegAsm.exe и TlbExp.exe, разработчики могут применять унаследованные компоненты COM в качестве строительных блоков для новых приложений .NET.

По сравнению с компонентами COM сборки легче создавать, развертывать и поддерживать. Маловероятно, что .NET когда-либо полностью заменит разработчикам COM, для которых скорость выполнения является основной задачей. Однако, скорее всего, разработчики приложений Web и программ, которые внутренне используются организациями, сочтут сборки .NET избавлением от ада DLL.

В этой главе рассматриваются два больших вопроса: 1) что такое службы COM+, как они разрабатываются и как работают; и 2) каким образом службы COM+ могут использоваться на платформе .NET в целом и в C#, в частности.

Мы рассмотрим первый вопрос в первой части этой главы. Даже если вы знакомы с MTS — предшественником служб COM+, вы узнаете много нового при рассмотрении новых служб, таких как очереди сообщений и события. Как будет показано, службы COM+ предоставляют намного больше, чем поддержка транзакций, — значительный объем готовой функциональности, где каждый профессиональный программист C# может найти что-то полезное.

Последняя часть главы посвящена второму вопросу: как службы COM+ используются на платформе .NET. Мы рассмотрим классы, интерфейсы и атрибуты, которые находятся в пространстве имен EnterpriseServices, а также утилиту RegSvcs.exe.

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

Давайте начнем с рассмотрения того, как появились службы COM+.

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

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

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

Службы COM+ начинали жизнь как дополнительный модуль Windows NT, называемый Сервер транзакций Microsoft (MTS). В настоящее время Windows 2000 определяет MTS как составную часть операционной системы, переименовывая ее в ходе процесса.

В дополнение ко всем исходным свойствам MTS, службы COM+ включают в себя новые возможности, в еще большей степени сокращающие объем кода, который должен написать разработчик компонентов.

Службы COM+, которые уже были представлены в MTS, включают в себя:

□ Обеспечение транзакций

□ Организацию пулов объектов

□ Оперативную активизацию объектов (JIT, Just-in-Time)

□ Безопасность

Новые службы, введенные COM+:

□ Поддержка событий

□ Очереди сообщений компонентов

□ Выравнивание нагрузки компонентов

В этой главе мы рассмотрим каждую из служб COM+, как старые, известные из MTS, так и новые, которые могут быть еще незнакомы. Но сначала кратко рассмотрим лучшего помощника COM+: "snap-in" служб компонентов (Component Services). (Snap-in является специальным типом программы, таким как SQL Server или IIS, который выполняется внутри интерфейса консоли управления Microsoft — ММС.)