在.NET程序之间的通信 [英] Communication between programs in .NET
问题描述
我要分开我的程序相互沟通的模块。它们可能是在相同的计算机上，但可能在不同的。
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.
我正在考虑两种方法：
- 创建一个类的所有细节。发送到通信层它。这一次其序列，将其发送，对方反序列化回班，比再处理它。
- 创建一个哈希表（键/值的东西）。把所有的数据在里面。发送到communicationlayer等等等等
所以它归结为VS hashtable中类。
So it boils down to hashtable vs class.
如果我认为松耦合，我喜欢哈希表。这很容易有一个模块的更新，包括在hastable新的额外的参数，可以不更新的另一边。
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.
有没有人解决了这个previously并有这个建议吗？
Has anyone tackled this previously and has suggestions about this?
谢谢！
编辑： 我已经授予点，这是最符合我原来的问题的答案，尽管它不是这是upvoted最之一
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服务（WSDL中定义paramers和返回类型）消息系统，其中消息的格式可能是XML或其他一些明确定义的格式。控制客户端和服务器的耦合的问题仍然是在所有情况下。
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.
什么跟你的哈希表怎么办？假设你的请求中包含名称和电话号码，突然你意识到你需要区分座机号和CELL-NUMBER。如果你只是改变了哈希表项使用新的值，则服务器需要改变的同时。假设在这一点上，你不只是有一个客户端和一个服务器，但可能涉及某种交换或经纪人制度，许多团队实施了许多客户，许多团队实现多台服务器。问所有的人都升级到在同一时间一个新的消息格式也是相当的承诺。
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.
因此，我们倾向于寻找回comptible解决方案，如添加剂的变化，我们preserve电话号码，并增加了新的领域。服务器现在容忍的消息containg无论是旧的或新的格式。
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.
不同的分布技术有不同的内置度宽容的向后兼容性的。当与序列化类处理你能处理旧版本和新版本？当使用WSDL处理，将消息解析器容忍添加剂的变化。
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）。你将有客户端和服务器之间的简单关系，例如你code和同时控制，可以自由支配自己的发布周期。如果否，则有利于灵活，使用哈希表或XML。
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）。即使你是在控制起来看看如何轻松地将序列化框架支持的版本。这可能是因为强类型，序列化类的接口将是更易于使用，提供您有什么要采取以进行更改界面的清晰画面。
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.
这篇关于在.NET程序之间的通信的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
