В чем преимущество использования COM над простой DLL?

Question

Предположим, что вы работаете только в мире C ++ (межязыковое взаимодействие не требуется). Какие преимущества / неудобства вы видите при использовании COM вместо простой базовой DLL? Как вы думаете, использование COM стоит хлопот, если вы не собираетесь использовать интерфейс на разных языках?

Answer 1

Все упоминают о том, что находится в плюсе колонки COM. Я упомяну пару отвлечений.

• Когда вы внедряете свою систему с помощью COM, вам нужно зарегистрировать COM-серверы (будь то in-proc или out-of-proc) при установке и отменить их регистрацию при удалении. Это может немного увеличить сложность вашей системы установки и, как правило, потребует перезагрузки, если пользователь сначала не остановит запущенные процессы.

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

• В соответствии с правилами COM, после публикации интерфейса его нельзя изменить. Само по себе это не является негативом, и вы можете даже утверждать, что это заставляет вас сделать тщательный дизайн перед отправкой интерфейса. Но правда в том, что никогда не бывает такого, и в производственном коде интерфейсы меняются. Вам, несомненно, нужно будет либо добавить методы, либо изменить сигнатуры существующих методов. Чтобы достичь этого, вы должны либо нарушить правила COM - что имеет плохие последствия - либо следовать правилам COM, которые сложнее, чем просто добавить параметр в функцию, как если бы вы использовали astraight DLL.

Answer 2

COM может быть полезен в простом старом C ++ для:

• Межпроцессное взаимодействие
• Плагин архитектуры
• Сценарии позднего связывания
• "Много, намного, больше ..." (тм)

Тем не менее, если вам это не нужно, не используйте его.

Answer 3

С DLL вы можете получить гораздо более тесную связь, в то время как COM очень точно ограничивает взаимодействие. В этом корень как достоинств, так и недостатков!

Вы получаете больше мощности и гибкости (например, наследовать от классов, определенных в DLL, а не в COM), но таким образом зависимость становится намного сильнее (необходимо перестроить пользователя для определенных изменений в DLL и т. Д.).

Часто особенно обидно то, что все библиотеки DLL и EXE должны использовать библиотеку и параметры времени выполнения одного типа (например, все динамически связаны с неотлаженной многопоточной версией msvcrt*, например - не может перестроить только одну используйте отладочную версию без очень вероятных ошибок!).

Поэтому более предпочтительной является более слабая связность COM, если только вам действительно не нужны виды более тесной связи в конкретном случае (например, среда, которая определенно требует, чтобы пользовательский код наследовал от своих классов, должна быть DLL ).

Answer 4

Если вы можете избежать, не используйте его. В моем последнем проекте COM привел довольно много ограничений к используемым интерфейсам C ++. Только представьте, что вы не можете просто передать std :: string, но должны использовать массив символов. В этом случае вы строите строку, а затем копируете ее в массив, который может обрабатываться COM.

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

Вы также не можете просто вызвать исключение, но должны инициализировать некоторый интерфейс COM IErrorInfo, который будет переброшен на другом конце.

Так что, если вам не нужно, не используйте его. Это определенно испортит ваш дизайн. И если вам это нужно, попробуйте оценить другие возможности взаимодействия: boost :: interprocess, zeroc ice ...

С уважением,

Ованес

Answer 5

Поскольку интерфейсы не зависят от какой-либо конкретной DLL, на самом простом уровне подход, подобный COM, по крайней мере освобождает вас от необходимости изменять dll, обслуживающую интерфейс под капотом, без необходимости перекомпилировать ваше приложение с новым именем dll.

Использование Full COM с интерфейсами, определенными в MIDL и прокси-заглушками, означает, что вы можете использовать COM для управления безопасностью потоков в процессе, межпроцессного обмена данными на одном ПК или даже для подключения к объекту COM-сервера на удаленном ПК.

Answer 6

Интерфейс IUnknown является хорошим базовым уровнем для поддержки в любом случае - он дает вам возможность добавлять функции, не ломая старых клиентов (QueryInterface) и всесторонний подсчет ссылок. Вы можете реализовать это, не покупая во всем в COM.

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

Ваша единственная дельта, которая не может быть вызвана другим языком, - это регистрация и фабрика классов.

Answer 7

• Регистрация и обнаружение
• Из-из-процесса
• Удаленный вызов

- это несколько дополнительных функций, которые вы бы получили. Даже поддержка транзакций может протекать без поддержки COM в наши дни.