DCOM 出了什么问题？
人们似乎对 DCOM 有很多敌意，我很想知道为什么。对于仍在使用 C++ 编写 Win32 SKD 的公司来说，是否有真正的理由在当前或未来的开发中不使用 DCOM？未来的某些 Windows 版本是否将不支持它？是否太脆弱，经常无法工作？与其他技术相比，它的实施是否过于复杂？这是怎么回事？
There seems to be a lot of enmity against DCOM, and I'm curious to understand why. For a company still writing to the Win32 SKD using C++, is there any real reason not to use DCOM in current or future development? Is some future version of Windows not going to support it? Is it too fragile and fails to work often? Is it too complicated to implement compared to other technologies? What's the deal?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
如果你只想用C++开发并部署在受控网络中，它可能仍然是一个不错的选择。
If you only want to develop in C++ and deploy in controlled network, it may still be a good choice.
我不喜欢 COM/DCOM，因为
“灾难性故障”是错误消息历史中最无用的错误消息。I dislike COM/DCOM because
"Catastrophic failure"is the most unhelpful error message in the history of error messages.嗯，DCOM 是 COM 的分布式版本，COM 本身非常复杂，很容易无意中做错事情（请参阅 这个最近的问题及其答案作为示例）。有了 DCOM，你就有更多的方式来伤害自己。
除此之外，它还可以工作，例如，它是在单独的进程中托管进程内 COM 组件的好方法。
Well, DCOM is a distributed version of COM and COM is very complex by itself and it's very easy to do something wrong unintentionally (see this recent question and the answer to it for examples). With DCOM you just have even more ways to hurt yourself.
Other than that it works and is for example a good way for hosting in-proc COM components in a separated process.
如果您尝试构建客户端服务器应用程序并希望通信跨越网络边界（例如互联网），那么 DCOM 可能会因防火墙而出现问题。
我曾开发过一个非常成功的服务器应用程序，该应用程序使用 DCOM 进行分发，我们通过创建 COM+ 服务器应用程序和导出应用程序代理让系统处理大部分复杂性。在这种情况下，只要我们所有的版本都同步，它就可以很好地工作。
If your trying to build a client server application and want the communication to go across network boundaries (for example the internet) then DCOM can be problematic due to firewalls.
I had worked on a very success server application which was distributed using DCOM, we let the system handle most of the complexity by creating COM+ Server Applications and exporting Application Proxies. In this case it worked very well as long as all of our versions were synched up.
我在 90 年代末使用 DCOM 实现了一个大型系统。尽管它运行得很好，但也存在一些问题。对于初学者来说，它使用不可预测的端口号进行通信。它不可扩展，并且使用 WCF 比使用 DCOM 好得多。
I implemented a large system using DCOM in the late 90's. Although it worked pretty well, there were a couple of issues. For starters it uses unpredictable port numbers for communication. It is not scalable, and you are much better off using WCF than DCOM.
我认为势头已经转向 SOAP 和其他 Web 服务技术，因为它：
我自己从未使用过 DCOM，所以我无法真正评论其总体质量或健康。
I think momentum has shifted to SOAP and other web service technology because it is:
I've never used DCOM myself, so I can't really comment on its general quality or fitness.