Симон Робинсон - C# для профессионалов. Том II

Чтобы понять, почему компоненты COM и компоненты .NET внутренне несовместимы, необходимо иметь общее понимание того, как работает COM. Далее следует существенно упрощенное объяснение. Более детальную информацию можно найти в книге "Professional COM Applications with ATL" издательства Wrox Press (ISBN 1861001703).

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

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

Каждый класс COM и каждый интерфейс, который он поддерживает, имеет 128-битный идентификатор, который гарантированно является уникальным во все времена и во всех местах. Эти глобально уникальные идентификаторы, или GUID, централизованно хранятся в реестре машины, и поддерживающие COM языки имеют средства для получения значения GUID компонента COM и использования его для вызова функциональности компонента.

Хотя COM предоставляет значительные преимущества, она имеет также недостатки. Первое: компоненты COM могут быть трудными для кодирования. В C++ разработка компонента COM включает реализацию стандартных интерфейсов COM и использование GUIDGEN.EXE для того, чтобы генерировать GUID для каждого класса и каждого интерфейса. (Хотя технологии, подобные VB и ATL Object Wizard упрощают процесс создания COM, они обеспечивают только подмножество свойств COM).

Второе: компоненты COM могут оказаться трудными для развертывания. Разработчики COM серверных компонентов предполагали обеспечить совместимость новых версий компонентов с более старыми, но не всегда это удавалось, поэтому установка нового приложения, которое ссылается на новую версию компонента COM, может внезапно дать отказ существующих приложений. Проблемы такого рода называются "адом DLL" и являются причиной большой головной боли и потерь времени.

Дополнительная информация о том, как .NET обращается с адом DLL, находится по адресу msdn.microsoft.com/library/techart/dplywithnet.htm.

Подход .NET к созданию компонентов использует многие возможности COM, игнорируя при этом ее недостатки. Компоненты должны иметь некоторый способ описания клиентам классов, которые они поддерживают. Вместо использования для этого GUID и реестра каждый файл компонента .NET инкапсулирует свое собственное описание во внутреннем сегменте, называемом манифестом(manifest).

Это означает, что размещение компонента выполняется просто: надо скопировать компонент .NET в папку исполнимого файла, который на него ссылается. Когда исполнимому файлу необходимо создать компонент, он просматривает в файле компонента в манифесте информацию, которая ему нужна. Различные версии одного и того же компонента могут существовать бок о бок на одной машине до тех пор, пока они хранятся в различных папках. (Существует центральная папка для хранения компонентов, которую можно сделать доступной для множества компонентов, она называется иногда "Global Assembly Cache" — Глобальный кэш сборок (см. главу 8).

Компоненты .NET также легко создавать в C# и VB.NET разработчик защищен от процесса создания манифеста. Разработчик создает просто проект библиотеки классов, заполняет его классами и позволяет компилятору выполнить грязную работу предоставления этих классов клиентам.

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

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

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

В типичной организации, вероятно, невозможно (или, по крайней мере, нежелательно) выбросить компоненты COM, которые были в ней разработаны, так как компоненты .NET сделаны хорошо. Следовательно, можно ожидать ссылок на унаследованные компоненты COM из нового кода .NET, по крайней мере, в первых проектах .NET масштаба предприятия. В частности, если создается новое приложение .NET поверх существующей базы данных, вероятно, захочется использовать существующие объекты COM доступа к данным в слое доступа к данным создаваемого проекта. Если доступ к данным происходит через унаследованные компоненты, то .NET реализует бизнес-правила и доставит данные в формы ASP.NET или Windows интерфейса пользователя.

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

Прежде чем погружаться в тонкости вопросов взаимодействия с унаследованными объектами COM, давайте кратко обсудим, как достичь такого взаимодействия. Наше объяснение строится с точки зрения IDE VS.NET, так как большинство читателей будут использовать его для написания своих программ C#, но альтернативные редакторы могут предоставить свои собственные эквивалентные методы.