2008-11-18 2 views
6

Каковы глубокие преимущества при использовании COM для разработки компонентов по WCF? Есть ли что-нибудь, что можно сделать с COM, а не с WCF?COM мертв?

ответ

8

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

Что касается WCF, могут возникнуть некоторые краевые случаи, которые COM может делать, а WCF не может, но что более важно, и относится к устаревшим материалам, заключается в том, что существуют привязки COM для почти каждого языка, который вы можете использовать стек Windows, но привязки WCF еще не готовы для всех (языки).

+2

Существует много кода сделано в COM ... портировать его на управляемой стороне ОГРОМНЫЙ спросить. например MS Office по-прежнему COM. Сделать слово или преуспеть снова с нуля было бы огромной ошибкой/временем. – Gishu 2008-11-18 15:55:24

+0

@ Гишу - Полностью согласен ... Офис и необходимость поддерживать обратную совместимость будут поддерживать COM дольше, чем что-либо еще. Переход на 64-битный в мейнстрим может изменить некоторое уравнение. – 2008-12-04 15:05:31

7

Зависит от того, насколько глубоко в систему вы хотите копать. COM никогда не «умрет», так же как неуправляемые языки никогда не будут.

Короче говоря, если вы разрабатываете настольные приложения для Vista +, вам, вероятно, больше не придется беспокоиться об использовании COM.

0

Если я не ошибаюсь, .NET предназначен для замены технологий, таких как COM и WFC. Есть ли причина (кроме устаревшего кода), что вы выбрали COM или WFC через .NET?

+0

WCF (основа связи Windows) является частью .NET Framework 3.0. Это не устаревшая технология. – 2008-11-18 07:47:08

4

Я не думаю, что COM мертв. Если вы посмотрите на Vista, она использует так много архитектуры и технологии COM. Каждая вещь в Vista - это COM Dll/Exe. Я чувствую себя по сравнению с XP, Vista использует так много COM.

Если мы хотим расширить что-либо в Vista, мы должны реализовать интерфейсы с использованием COM.

4

Есть несколько различных аспектов:

  1. компонента, которые будут работать на и взаимодействовать с несколькими компьютерами (как служба)
  2. компоненты, которые работают только на местном уровне, и взаимодействовать с компонентами, реализуемых несколькими поставщиками через ABI ,
  3. Компоненты, которые были созданы одним поставщиком без каких-либо взаимодействий со сторонними компонентами.
  4. Компоненты из нескольких поставщиков, которые доступны в исходном коде, которые могут быть скомпилированы в одно приложение.

(ABI = двоичный интерфейс приложения. COM является примером ABI.)

В аспекте 1, COM довольно много мертв.

Аспект 2 по-прежнему требует COM, и он будет продолжать оставаться. Компонент Windows Imaging - отличный пример такой расширяемости, позволяющий любому реализовать новые кодеки изображений. .Net является сильным соперником в этом аспекте.

Для аспекта 3 COM по-прежнему стоит учитывать, но это решение должно быть принято для каждого поставщика программного обеспечения. Разработчик компонентов для собственного использования может однажды быть продан как продукт. .Net, кажется, тоже хороший выбор.

Для аспекта 4 можно просто адаптировать и комбинировать исходные коды из многих проектов с открытым исходным кодом. Нет необходимости в COM или любом ABI.

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