创建COM +应用程序时,向导可以在库和服务器应用程序之间进行选择。
服务器应用程序在单独的进程中激活,这可以用于廉价地将64位使用者与32位进程内COM组件互操作。
在调用者进程中激活的库应用程序有什么用?为什么要使用它们而不是普通的旧进程内COM服务器?
答案 0 :(得分:2)
有几个:
性能 - 它更快一点,因为您不必通过消息自动化(编组和解组)
隔离 - 如果许多不同的应用程序正在使用库,则每个应用程序都有自己的副本。在处理MTA(多线程公寓)和STA(单线程公寓模型)之间的差异时,这一点最为重要
IN-PROC服务器(在调用者的进程中实际上是一个进程外)由所有不同的调用者共享(这是获得廉价IPC / RPC的好方法)
好的我正在编辑一些更多的定义,以及更多的参考:
概念的内容将在Tim Ewald的优秀书籍“Transactional COM +”ISBN:0-201-61594-0
中的第2章中讨论。因此,直接引用第2章的摘要: “一个对象可以使用对象上下文与使用调用上下文的给定因果关系进行交互。这两个对象提供了与COM +运行时服务交互的接口。这种编码风格”进入上下文“使COM +开发与传统COM非常不同发展“。
最后,第2章讨论了“为什么要使用图书馆?”, (这与你的问题不同,为什么不是普通的旧COM?) 他的论点主要表明使用COM对象的原因相同, 1.每个应用程序都有自己的实例。 2.加载到非DLLhost.exe进程。 3.少开销。 4.简单部署常见对象。
所以最重要的是,如果你不是分布式的,而不是自然的事务性,那么在COM上使用COM +可能没有什么好处。但是,如果您编写COM +应用程序并将其部署为LIBRARY应用程序,它将更像COM组件。
希望有所帮助。
答案 1 :(得分:1)
主要目的是受益于COM+ application contexts。
IObjectContext
或IObjectContextActivity
的CoGetObjectContext将从纯进程内组件返回E_NOTINTERFACE,而它将在COM +库应用程序(当然还有服务器应用程序)中成功运行。 / p>
ISecurityCallContext
的{{3}}也可以使用安全上下文。
它与性能或隔离无关。
作为网站说明,检查COM +库应用程序可用内容的一种方法是运行dcomcnfg.exe导航到组件服务,计算机,我的电脑,COM +应用程序,创建新的库应用程序并检查仍然启用的内容(相反)到服务器应用程序)。