.NET 中程序之间的通信
我想将程序的模块分开以相互通信。它们可能位于同一台计算机上，但也可能位于不同的计算机上。
我正在考虑两种方法：
- 创建一个包含所有详细信息的类。将其发送到通信层。这一方将其序列化，发送它，另一方将其反序列化回类，然后进一步处理它。
- 创建一个哈希表（键/值事物）。将所有数据放入其中。将其发送到通信层等
所以它归结为哈希表与类。
如果我认为“松散耦合”，我更喜欢哈希表。更新一个模块很容易，在 hastable 中包含新的额外参数，而无需更新另一侧。
然后，对于一个类，我再次进行编译时类型检查，而不是运行时。
有人以前解决过这个问题并对此有建议吗？
谢谢！
编辑： 我已为与我原来的问题最相关的答案评分，尽管它不是获得最多支持的答案
I want to separate modules of my program to communicate with each other. They could be on the same computer, but possibly on different ones.
I was considering 2 methods:
- create a class with all details. Send it of to the communication layer. This one serializes it, sends it, the other side deserializes it back to the class and than handles it further.
- Create a hashtable (key/value thing). Put all data in it. Send it of to the communicationlayer etc etc
So it boils down to hashtable vs class.
If I think 'loosely coupled', I favor hashtable. It's easy to have one module updated, include new extra params in the hastable, without updating the other side.
Then again with a class I get compile-time type checking, instead of runtime.
Has anyone tackled this previously and has suggestions about this?
Thanks!
edit:
I've awarded points to the answer which was most relevant to my original question, although it isn't the one which was upvoted the most
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
听起来您只是想将一些 IPC（进程间通信） 合并到您的系统中。
在 .NET（3.0 及以上）中实现此目的的最佳方法是使用 Windows Communication Foundation (WCF) - 由 Microsoft 开发的通用框架，用于在通用基础上以各种不同方式（传输）进行程序之间的通信。
尽管我怀疑您可能出于效率和稳健性的目的而希望使用命名管道，但还有许多其他可用的传输，例如 TCP 和 HTTP（请参阅 这篇 MSDN 文章），更不用说从二进制到 XML 到 JSON 的各种序列化格式了。
It sounds like you simply want to incorporate some IPC (Inter-Process Communication) into your system.
The best way of accomplishing this in .NET (3.0 onwards) is with the Windows Communication Foundation (WCF) - a generic framework developed by Microsoft for communication between programs in various different manners (transports) on a common basis.
Although I suspect you will probably want to use named pipes for the purposes of efficiency and robustness, there are a number of other transports available such as TCP and HTTP (see this MSDN article), not to mention a variety of serialisation formats from binary to XML to JSON.
在分布式系统设计中往往会遇到这类问题。它出现在 Web 服务（定义参数和返回类型的 WSDL）消息系统中，其中消息的格式可能是 XML 或其他一些定义良好的格式。在所有情况下，控制客户端和服务器耦合的问题仍然存在。
你的哈希表会发生什么情况？假设您的请求包含“NAME”和“PHONE-NUMBER”，突然您意识到需要区分“LANDLINE-NUMBER”和“CELL-NUMBER”。如果您只是更改哈希表条目以使用新值，那么您的服务器也需要同时更改。假设此时您不仅有一个客户端和一台服务器，而且可能正在处理某种交换或代理系统，许多客户端由许多团队实现，许多服务器由许多团队实现。要求所有这些同时升级到新的消息格式是一项艰巨的任务。
因此，我们倾向于寻求向后兼容的解决方案，例如附加更改，我们保留“电话号码”并添加新字段。服务器现在可以容忍包含旧格式或新格式的消息。
不同的分发技术对于后向兼容性有不同的内置容忍度。在处理序列化类时，您可以处理旧版本和新版本吗？在处理 WSDL 时，消息解析器是否能够容忍附加更改。
我会遵循以下过程：
1）。您是否在客户端和服务器之间有一个简单的关系，例如您是否编码和控制两者，可以自由地规定它们的发布周期。如果“否”，则倾向于灵活性，使用哈希表或 XML。
2）。即使您处于控制之中，也要看看您的序列化框架支持版本控制的容易程度。如果您清楚地了解要对接口进行更改，那么强类型的序列化类接口可能会更容易使用。
One tends to hit this kind of problem in distributed systems design. It surfaces in Web Service (the WSDL defining the paramers and return types) Messaging systems where the formats of messages might be XML or some other well-defined format. The problem of controlling the coupling of client and server remains in all cases.
What happens with your hash table? Suppose your request contains "NAME" and "PHONE-NUMBER", and suddenly you realise that you need to differentiate "LANDLINE-NUMBER" and "CELL-NUMBER". If you just change the hash table entries to use new values, then your server needs changing at the same time. Suppose at this point you don't just have one client and one server, but are perhaps dealing with some kind of exchange or broker systems, many clients implemented by many teams, many servers implemented by many teams. Asking all of them to upgrade to a new message format at the same time is quite an undertaking.
Hence we tend to seek back-comptible solutions such as additive change, we preserve "PHONE-NUMBER" and add the new fields. The server now tolerates messages containg either old or new format.
Different distribution technologies have different in-built degrees of toleration for back-compatibility. When dealing with serialized classes can you deal with old and new versions? When dealing with WSDL, will the message parsers tolerate additive change.
I would follow the following though process:
1). Will you have a simple relationship between client and server, for example do you code and control both, are free to dictate their release cycles. If "no", then favour flexibility, use hash tables or XML.
2). Even if you are in control look at how easily your serialization framework supports versioning. It's likely that a strongly typed, serialized class interface will be easier to work with, providing you have a clear picture of what it's going to take to make a change to the interface.
您可以使用 Sockets、Remoting 或 WCF，eash 各有利弊。
但如果性能并不重要，您可以使用 WCF 并序列化和反序列化您的类，为了获得最大性能，我建议使用套接字
You can use Sockets, Remoting, or WCF, eash has pros and cons.
But if the performance is not crucial you can use WCF and serialize and deserialize your classes, and for maximum performance I recommend sockets
对远程处理的内置支持发生了什么变化？
http://msdn.microsoft.com/en-us/library/aa185916。 aspx
如果您愿意，它可以在 TCP/IP 或 IPC 上运行。它比 WCF 更快，并且对您的代码非常透明。
What ever happened to the built in support for Remoting?
http://msdn.microsoft.com/en-us/library/aa185916.aspx
It works on TCP/IP or IPC if you want. Its quicker than WCF, and is pretty transparent to your code.
根据我们过去几年广泛使用 WCF 和各种绑定的经验，我们发现 WCF 不值得这么麻烦。
正确使用 WCF 非常复杂，包括正确处理通道上的错误，同时保持良好的性能（我们很早就放弃了 wcf 的高性能）。
对于经过身份验证的客户端场景，我们切换到 http rest（没有 wcf）并执行 json/protobuf 负载。
对于高速非身份验证场景（或至少非 Kerberos 身份验证场景），我们现在使用 Zeromq 和 Protobuf。
In our experience using WCF extensively over the last few years with various bindings we found WCF not be worth the hassle.
It is just to complicated to correctly use WCF including handling errors on channels correctly while retaining good performance (we gave up on high performance with wcf early on).
For authenticated client scenarios we switched to http rest (without wcf) and do json/protobuf payloading.
For high-speed non-authenticated scenarios (or at least non-kerberos authenticated scenarios) we are using zeromq and protobuf now.