Какова цель приложений библиотеки COM +? - PullRequest
5 голосов
/ 19 ноября 2009

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

Серверное приложение активируется в отдельном процессе, и его можно использовать для дешевого взаимодействия 64-битных потребителей с 32-битными внутрипроцессорными COM-компонентами.

Какая польза от библиотечных приложений, которые активируются прямо в процессе вызова? Зачем использовать их вместо старых старых внутрипроцессных COM-серверов?

Ответы [ 2 ]

2 голосов
/ 19 ноября 2009

Есть несколько:

  1. Производительность - это немного быстрее, так как вам не нужно проходить автоматизацию сообщений (маршалинг и демаршаллинг)

  2. Изоляция - если много разных приложений используют библиотеку, то у каждого будет своя копия. Этот момент наиболее важен, когда речь идет о различиях между MTA (многопоточные квартиры) и STA (однопоточные модели квартир)

Сервер IN-PROC (который на самом деле является вне процессов, вне процесса вызывающей стороны) используется всеми разными вызывающими сторонами (это отличный способ иметь дешевые IPC / RPC)

Хорошо, я редактирую еще несколько определений и немного больше ссылок:

  1. Контекст - это действительно все состояние вокруг использования объекта.
  2. причинно-следственная связь на самом деле является понятием, подобным понятию, указывающим на использование объекта в контексте. («Причинность - это распределенная цепочка вызовов метода COM, которая охватывает любое количество контекстов в любом количестве процессов» - из ISBN: 0-201-61594-0)

Эти понятия обсуждаются на 30 страницах главы 2 из превосходной книги Тима Эвальда «Транзакционный COM +» ISBN: 0-201-61594-0

Итак, взяв прямую цитату из резюме главы 2: «Объект может взаимодействовать со своим контекстом, используя контекст объекта, и с заданной причинностью, используя контекст вызова. Эти два объекта предоставляют интерфейсы для взаимодействия со службами времени выполнения COM +. Этот стиль кодирования,« достижение контекста », сильно отличает разработку COM + от классического COM. развития ".

Наконец, в главе 2 обсуждается вопрос «Почему используются библиотеки?», (что отличается от вашего вопроса, почему бы не просто старый COM?) Его аргументы в основном указывают на те же причины использования COM-объекта, 1. У каждого приложения есть свой экземпляр. 2. Загрузите в не DLLhost.exe процесс. 3. Намного меньше накладных расходов. 4. Простое развертывание общих объектов.

Итак, суть в том, что если вы не распределенный и не транзакционный по своей природе, то использование COM + по сравнению с COM может не иметь никакого реального преимущества. Но если вы напишите приложение COM + и развернете его как приложение LIBRARY, оно будет вести себя как компонент COM.

Надеюсь, это поможет.

1 голос
/ 15 июня 2015

Основная цель - извлечь выгоду из контекста приложения COM + .

CoGetObjectContext для IObjectContext или IObjectContextActivity вернет E_NOTINTERFACE из чистого внутрипроцессного компонента, в то время как он будет успешно работать в приложении библиотеки COM + (и, конечно, в серверном приложении).

Контекст безопасности также доступен через CoGetCallContext для ISecurityCallContext.

Это не имеет ничего общего с производительностью или изоляцией.

Как примечание сайта, один из способов проверить, что доступно для библиотечных приложений COM +, - запустить dcomcnfg.exe, перейти к компонентам Службы, Компьютеры, Мой компьютер, приложение COM +, создать новое библиотечное приложение и проверить, что еще включено (в отличие от этого). на серверное приложение).

...