【发布时间】：2010-12-23 06:24:45
【问题描述】：
似乎对 DCOM 有很多敌意，我很想知道为什么。对于一家仍在使用 C++ 编写 Win32 SKD 的公司，是否有任何真正的理由不在当前或未来的开发中使用 DCOM？某些未来版本的 Windows 将不支持它吗？是不是太脆弱，不能经常工作？与其他技术相比，实施起来是否过于复杂？有什么关系？
【问题讨论】：
-
一切 ;)（开个玩笑）
标签： dcom
【发布时间】：2010-12-23 06:24:45
【问题描述】：
- 安全模型。尤其是当计算机不在同一个域中（或根本不在域中）时。
- 为 Visual Basic（原始，不是 .NET）建模的自动接口，已过时且不适合在其他语言中使用。
如果你只想用 C++ 开发并部署在受控网络中，它可能仍然是一个不错的选择。
【讨论】：
-
跨本地操作系统边界（另一台机器上的任何东西）的安全问题怎么强调都不过分。 “管理” DCOM 安全性是完全不可能的。 （祝你好运尝试追踪错误或解释错误消息。）
我不喜欢 COM/DCOM，因为"Catastrophic failure" 是错误消息历史上最无用的错误消息。
【讨论】：
-
这将是用户的“感觉良好”消息。这样他们就知道自己做对了。
-
ERROR_ALREADY_EXISTS 总结一下。
嗯，DCOM 是 COM 的分布式版本，COM 本身非常复杂，很容易无意中做错事（参见this recent question 及其答案示例）。使用 DCOM，您将拥有更多伤害自己的方式。
除此之外，它还可以工作，例如，它是在单独的进程中托管进程内 COM 组件的好方法。
【讨论】：
-
如果您了解指针和引用计数器，我实际上发现 COM 是很容易理解的，而且相当简单。
-
相信我，IUnknown 成员函数只是一个开始。然后是公寓、并发和其他可能导致可怕痛苦的东西。
-
那么对于需要通信的本地 win32 SDK 服务和客户端应用程序，您会推荐什么？是的，DCOM 很复杂，但满足这些要求的技术不是吗？
-
如果你有两个进程直接使用 RPC 通常会更容易和更可靠。但是你不会有“对象”——你必须手动维护服务器上的状态。
如果您尝试构建客户端服务器应用程序并希望通信跨越网络边界（例如互联网），那么 DCOM 可能会因防火墙而出现问题。
我曾开发过一个非常成功的使用 DCOM 分发的服务器应用程序，我们通过创建 COM+ 服务器应用程序和导出应用程序代理让系统处理大部分复杂性。在这种情况下，只要我们所有的版本都同步，它就可以很好地工作。
【讨论】：
-
我忘了提到我们的客户端和服务器将位于同一台机器的本地，由我们编写并部署在一起，因此没有网络或同步问题。
我在 90 年代后期使用 DCOM 实现了一个大型系统。尽管它工作得很好，但也存在一些问题。对于初学者，它使用不可预测的端口号进行通信。它不可扩展，而且使用 WCF 比使用 DCOM 要好得多。
【讨论】：
-
不幸的是，我们仅限于 Win32 SDK - 不允许 .NET。我知道，我知道，但我不制定规则
-
我仍然相信您可以使用 Web 服务 - 我很确定有 C++ 的 SOAP 包。
我认为势头已经转移到 SOAP 和其他 Web 服务技术，因为它是：
- 在有防火墙的情况下更容易部署系统
- 没有供应商锁定
我自己从未使用过 DCOM，因此我无法评论它的总体质量或适用性。
【讨论】：
-
我想我应该提到我的用途是用于本地 DCOM - 同一台机器上的客户端和服务器。将所有内容都转换为 ASCII，然后用更多的 ASCII 标签包装，然后解析 ASCII 结果是非常低效的。
-
啊，我听到了。是的，SOAP 也有自己的问题。