几天后我开始阅读COM。 然后我的一个团队成员说这是一个古老的技术，现在没有人使用这个技术。
我的问题是：
1）如果这是一个古老的技术，那么有什么select呢。
2）为什么我不需要使用COM。 即COM的缺点是什么？
与C ++一样，COM是一种“老技术”。 只是因为旧的并不意味着它已经过时了。 微软不断回来的原因（Windows 8大量使用它）是因为它是一个相对低开销的基于对象的技术。 在使用COM之前没有大的运行时间来初始化（尽管一个组件可以在需要的时候初始化运行时间，例如.NET CCW）。
界面/实现边界保持严格分离，所以它以面向对象的方式暴露Windows功能（以及Windows Shell基于COM的DirectX）非常有用。
COM对于什么是COM以及在COM之上构建什么都有一个普遍的误解。 ActiveX，DCOM，OLE，COM +等建立在COM上，但不定义什么COM。 COM本身作为核心技术一直保持相对简单。
我说相对来说COM是不完美的。 公寓模式可能会导致重大问题，例如跨公寓编组需要应用程序来抽取消息队列。 早在九十年代后期，人们就开始疯狂地使用COM组件，并且在应用程序中造成了不必要的复杂性。 但是，这是一个经过严格测试的技术，在正确使用的时候效果很好，特别是对于第三方的功能暴露或消费。 如果你想真正理解Windows API，你需要知道COM是如何工作的。
1）如果这是一个古老的技术，那么有什么选择呢。
COM肯定是老的。 微软的“替代品”是.NET，但意味着你需要和CLR一起玩（所以原生的C ++不能一起玩，你需要C ++ / CLI）。 现在叫做WinRT（Windows Runtime）。 WinRT目前仅适用于Windows 8和Windows server 2012.在最低级别上，WinRT实际上是COM，但是微软已经重新考虑了它的许多缺陷。 平台/语言不可知的替代品包括谷歌协议缓冲区，Apache Thrift和SOAP。
2）为什么我不需要使用COM。 即COM的缺点是什么？
COM的主要用途是进程间通信（IPC）。 例如，如果您有两种编程语言编写的应用程序，并希望它们进行通信，则COM是一个（特定于Windows的）解决方案。 COM在90年代被广泛用于C ++和VB6应用程序之间的通信。 如果你不需要IPC，那么你的COM的前景是相当低的。 今天我们最常用的COM是通过本地C ++应用程序和C＃编写的托管.NET应用程序来执行IPC。
最新的大型微软“技术”，用于编写Windows 8 metro应用程序的WinRT运行时（无论它们现在被称为…）完全依赖于COM，所以它肯定不会过时。