关于设计选择 [英] Regarding the design choices

问题描述

我需要设计遗留(基于MFC的VC ++应用程序)和.NET GUI应用程序(将要用C#构建)之间的双向分布式通信.我考虑过几种方法，例如托管C ++(IJW)，WCF(作为通信框架)，套接字，命名管道.请提出建议.

解决方案

首先，"Managed C ++"已由您标记的C ++/CLI取代，因此这几乎不是一个选择.其他所有内容实际上都取决于您的要求的详细信息，甚至取决于您对技术的熟悉程度.在这种情况下，无法证明仅使用此内容，别无其他"类型的任何建议.

不幸的是，WCF的非托管部分(旧版MFC应用程序)对我来说似乎太麻烦了，请参阅 COM互操作 [ 解决方案

First, "Managed C++" was superseded by C++/CLI which you tag, so this is hardly an option. Everything else really depends on details of your requirements and even of the level you are familiar with the technologies. In this case, it''s not possible to justify any advice of the type "use just this, nothing else".

Unfortunately, WCF for unmanaged part (legacy MFC application) seems too much of a hassle to me, see http://stackoverflow.com/questions/686452/create-wcf-service-for-unmanaged-c-clients[^].

Sockets or Named Pipes? Both seem reasonable. I think, with Sockets its somewhat easier to write more portable code.

—SA

WCF
Seems lake a hassle, to me, to write a host implementation of WCF in unmanaged C++.

Sockets
This is an option, however I''ve never really used them so I don''t know how feasible it is. That said if you need to communicate with something like Java where you can''t use Named Pipes.

Named Pipes
I would go with this one, if you''re using .NET 3.5 or above as Named pipes wasn''t introduced before .NET 3.5 . Note if you intend on using Mono then I''m not sure if Mono even implements Named Pipes.

MSMQ
Is also an option, though I guess that it is not a good one in your case, without knowing exactly what you want to do.

If you want to get the job done in a hurry - use COM Interop[^]

.Net has great support for COM, and COM enabling an MFC app is usually a straight forward process.

Best regards
Espen Harlinn

这篇关于关于设计选择的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！