COM +库应用程序的目的是什么?

创buildCOM +应用程序时,向导会提供在库和服务器应用程序之间进行select。

一个服务器应用程序在一个单独的进程中被激活,这可以用来廉价地使64位消费者与32位进程内COM组件互操作

在调用者进程中被激活的库应用程序有什么用处? 为什么使用它们而不是简单的旧的进程内COM服务器?

Solutions Collecting From Web of "COM +库应用程序的目的是什么?"

有几个:

  1. 性能 – 由于您不必经历消息自动化(编组和解组),速度会更快一些,

  2. 隔离 – 如果许多不同的应用程序正在使用该库,则每个应用程序都拥有自己的副本。 当处理MTA(多线程公寓)和STA(单线程公寓模型)之间的差异时,这一点是最重要的,

IN-PROC服务器(这实际上是一个进程外,从调用者的进程中)被所有不同的调用者共享(这是一个有便宜的IPC / RPC的好方法)

好吧,我正在编辑一些更多的定义,并多一点参考:

  1. 上下文实际上就是使用对象的全部状态。
  2. 因果关系实际上是一个像概念一样表示在上下文中使用对象的线程。 (“因果关系是COM方法调用的分布式链,跨越任意数量的进程中的任意数量的上下文” – 来自ISBN:0-201-61594-0)

这些概念在Tim Ewald出色的书“Transactional COM +”第二章的约30页中讨论。ISBN:0-201-61594-0

因此,从第2章的总结中直接引用:“一个对象可以使用对象上下文和使用调用上下文的给定因果进行交互,这两个对象提供了与COM +运行时服务交互的接口,这种编码风格,深入到上下文中“使得COM +的开发与经典的COM开发非常不同。”

最后,第2章讨论了“为什么使用图书馆应用程序?”(这与您的问题不同,为什么不只是简单的旧COM?)他的论点主要表明了使用COM对象的相同原因:1.每个应用程序都有自己的实例。 2.加载到非DLLhost.exe进程。 3.少开销。 4.普通对象的简单部署。

所以底线是,如果你不是分布式的,而不是Transactional In Nature,那么在COM上使用COM +可能没有真正的优势。 但是,如果您编写COM +应用程序并将其作为LIBRARY应用程序进行部署,则它将更像COM组件。

希望有所帮助。

主要目的是从COM +应用程序上下文中受益。

用于IObjectContextIObjectContextActivity CoGetObjectContext将从纯进程内组件返回E_NOTINTERFACE,而它将成功在COM +库应用程序(当然还有服务器应用程序)中工作。

安全上下文也可以通过CoGetCallContext for ISecurityCallContext

这与性能或隔离无关。

作为一个站点的说明,检查COM +库应用程序可用的一种方法是运行dcomcnfg.exe导航到组件服务,计算机,我的电脑,COM +应用程序,创建一个新的库应用程序,并检查什么仍然启用(而不是服务器应用)。