假设您只在C++世界中工作(不需要跨语言互操作).您在使用COM而不是简单的基本DLL时看到了哪些优点/不便？如果你不打算使用不同语言的界面,你认为使用COM是值得的吗？
每个人都在提及COM加列中的内容.我会提到一些缺点.
使用COM实现系统时,需要在安装时注册COM'服务器'(无论是进程内还是进程外),并在卸载时注销它们.这可能会略微增加设置系统的复杂性,并且往往需要重新启动,除非用户首先小心地删除正在运行的进程.
与执行相同操作的其他标准方法相比,COM速度较慢.这个评论可能会产生很多仇恨,也许会产生一些贬低,但事实是,在某些时候你需要编组数据,这是昂贵的.
根据COM规则,一旦界面发布,就永远不会改变.这本身并不是消极的,您甚至可能会争辩说它会在发布界面之前强制您进行彻底的设计.但事实是,从来没有这样的事情,并且在生产代码接口中也会发生变化.毫无疑问,您需要添加方法或更改现有方法的签名.为了实现这一点,你必须要么破坏COM的规则 - 这会产生不良影响 - 或者遵循COM的规则,这些规则比仅仅使用astraight DLL一样向函数添加参数更复杂.
COM在普通的旧C++中非常有用:
也就是说,如果您不需要它,请不要使用它.
使用DLL,您可以获得更紧密的耦合,而COM可以非常精确地限制交互.这是优点和缺点的根源!
您获得了更多的功能和灵活性(例如,从DLL中定义的类继承,在COM中不可行),但依赖性因此更强(需要重建用户以对DLL进行某些更改等).
通常特别令人烦恼的是,所有DLL和EXE必须使用相同类型的运行时库和选项(例如,所有动态链接到非调试多线程版本msvcrt*- 例如,无法重建只使用调试版本而不会产生调试版本很可能是错误!).
因此,COM的松散耦合通常是可取的,除非您在特定情况下确实需要更紧密耦合的交互类型(例如,框架,它肯定要求用户代码从其类继承,应该是DLL).
| 归档时间： |
|
| 查看次数： |
2554 次 |
| 最近记录： |