与普通的DLL相比，使用COM有什么优势？

Question

假设您只在C++世界中工作(不需要跨语言互操作)。您认为使用COM而不是普通的基本DLL有什么优点/不便之处？如果您不打算使用来自不同语言的接口，您认为使用COM值得麻烦吗？

Answer 1

每个人都在提到COM's plus专栏中的内容。我会提到一些贬损。

• 使用COM实现系统时，需要在安装时注册COM“服务器”(无论它们是进程内服务器还是进程外服务器)，并在卸载时注销它们。这可能会略微增加设置系统的复杂性，并且往往需要重新启动，除非用户首先小心地销毁正在运行的进程。与做同样事情的其他标准方法相比，
• COM速度很慢。这条评论可能会引起很多人的反感，可能还会有一些反对票，但事实是，在某些时候，你需要编组数据，这是COM规则的expensive.
• According，一旦接口发布，它就永远不能改变。这本身并不是负面的，你甚至可能会认为它迫使你在发布界面之前进行彻底的设计。但事实是，世界上没有永远不会发生的事情，而且在生产中，代码接口也会发生变化。毫无疑问，您将需要添加方法或更改现有方法的签名。为了做到这一点，你必须要么打破COM的规则--这会有坏的影响--要么遵循COM的规则，这些规则比你只需在函数中添加一个参数要复杂得多，就像你使用一个动态链接库那样。

Answer 2

COM在普通的老式C++中很有用，用于：

• 进程间communication
• Plugin architectures
• Late binding scenarios
• "Much，更多，更多...“(tm)

也就是说，如果你不需要它，就不要使用它。

Answer 3

使用DLL，您可以获得更紧密的耦合，而COM则非常精确地限制交互。这就是优点和缺点的根源！

您获得了更多的功能和灵活性(例如，从DLL中定义的类继承，但在COM中是不可行的)，但依赖性也因此更强(需要为DLL的某些更改重新构建用户，等等)。

通常，尤其令人难堪的是，所有all和EXE必须使用相同类型的运行时库和选项(例如，所有动态链接到msvcrt*的非调试多线程版本--不能只重新构建一个来使用调试版本，而不会导致很可能的错误！)。

因此，COM的松散耦合通常是可取的，除非您在特定情况下确实需要更紧密耦合类型的交互(例如，一定需要用户代码从其类继承的框架应该是DLL)。