• Microsoft .NET
  • C#.NET
  • Решение 11 распространенных проблем в многопоточном коде

Углубление в C# - Взаимодействие с COM

ОГЛАВЛЕНИЕ

 

Джон: О каком переносе на платформу, в инфраструктуре которой нет поддержки COM объектов, может идти речь?

Хейлсберг: Это действительно возможно. COM вообще не нужен для стандартизации C# или CLI. C# имеет модель классов, которая богата сама по себе, а COM это всего лишь один из взглядов на то, как приложения могут взаимодействовать. Но ничего в основах C# или CLI не говорится о том, что это должен быть COM, GUID, HRESULT, Addref или Release. Ничего подобного. Общая среда выполнения .NET полностью исключает это. Но дает прекрасную возможность взаимодействия посредством COM, о котором я буду всегда думать как об очень важной особенности, по причинам ранее указанным. Но вовсе не необходимой.

Гудхью: Я думаю, что некоторые из предыдущих вопросов имеют своей причиной то, что мы выпустили начальную версию руководства по языку, которая свободно доступна. Microsoft создала ее на встречах, где мы думали в первую очередь в терминах платформы Microsoft .NET. В результате мы ссылались на такие вещи, как COM и DLL, когда, например DLL одно из решений более глобальной проблемы - использование native кода на заданной платформе. Одна из выгод работы с организацией по стандартизации и работы с такими людьми, как IBM, с которыми мы создавали SOAP спецификацию, это то, что мы не делаем таких ссылок, которые затем будут нас ограничивать как, например, платформа COM в будущих версиях спецификаций.

Как сказал Андерс, взаимодействие с COM и его поддержка очень важна для нас и для нынешних клиентов Microsoft. Я думаю, мы сделали полезную работу, включив поддержку COM в платформу .NET. Но люди из индустрии слышали много раз, как мы используем слова COM и DLL. Они заключили, что платформа .NET только для Windows, в чем они ошибаются.

Хейлсберг: И мне кажется, что раз COM взаимодействие очень важно для Microsoft и для людей, которые занимаются разработками на платформе Microsoft, стандартизация C# и CLI должна позволить в других реализациях придать большее значение взаимодействию с платформой, на которой реализуется язык.

Осборн: Вы не будете настаивать на понятиях "чистой C#" и "чистой .NET" реализации?

Хейлсберг: Что такое "чистый"? Как много "чистых" Java приложений существует? Я думаю очень и очень мало. Но это числа. Давайте возьмем пример. Люди хотят использовать существующий код. Нельзя требовать от компаний, отказываться от имеющихся вещей.

Гудхью: Был ли у вас шанс говорить с Роджером Сешионс (Roger Sessions) [прим.ред. Роджер Сешионс - президент ObjectWatch и автор COM+ and the Battle for the Middle Tier.] ?

Осборн: Нет не было.

Гудхью: Роджер занимался интересной частью спецификации EJB (Enterprise JavaBeans), которая говорила о допустимых для производителей расширениях. Расширения производителей содержат такие вещи, как управление транзакциями, которые очень важны в создании корпоративных систем, с точки зрения защиты, передачи сообщений и так далее. В статье Сешионс грубо перечисляет одиннадцать областей функциональности, которые допускаются в реализациях, зависимых от производителя. Если вы возьмете IBM Websphere, как свою EJB реализацию, код, EJB который вы будете писать, будет несомненно приковывать вас к Websphere. Так что разговоры о том, что Java "стопроцентно чиста" - не правда. Существует очень хорошее интервью с Джеймсом Гослингом (James Gosling) на сайте разработчиков IBM. Он говорит, что реальные "написал однажды - запускается везде", 100% "чистые" приложения - в действительности бестолковая идея, и вообще предмет маркетинга. Он сказал сгоряча: "Мы даже не думали, что у нас будет возможность переносить все это, и изначально ее не было". И это изобретатель языка говорит, что никакой "чистоты" при переносимости не существует.

Осборн: Не оставили ли мы без внимания какие-либо важные особенности и новации C#, о которых вы хотели бы сказать?