我正在构建一个将与嵌入式设备通信的 .net 应用程序（xp、vista、7）。我将能够通过 IP、串行端口和调制解调器进行连接。 问题：我是否应该在我的应用程序中允许某种类型的开放连接，允许我通过操作系统中可能设置的其他通道连接到设备，只是为了允许未来的可扩展性，而无需真正更改设备上的任何内容？我只是在想象操作系统将能够为所有可能通过操作系统设置到设备的通信通道提供服务。就像管理员通过 SMTP 或其他协议设置一些通道一样。 我只是不想让自己陷入困境而忽略一些更开放的架构。
谢谢。
【问题讨论】：
标签： .net networking embedded
我会说：不。
原因 1：不要设计你不需要的功能。
原因 2：如果另一个系统需要访问，它可以使用 TCP，或者通过分离器使用串行端口。不确定调制解调器有什么可能。类似的功能很难自己实现和完善。
【讨论】：
我对你的问题有点困惑，但我认为你的意思是你应该将通信方法与应用程序中的更高级别代码隔离开来。
答案是肯定的，在您的应用程序中创建一个抽象层，并让该层通过您需要的任何方式（调制解调器、IP、串行等）处理与设备的通信。这可能最好通过定义一个支持所需通信调用的接口然后创建实现该接口的类来完成所选通信方法所需的工作。这样一来，您的更高级别的代码就不必关心使用哪种通信方法，而不必选择一种。
通过使用这种方法，可以很容易地向软件添加通信方法。根据您设备的操作编写进行通信脏工作的类，并添加一些方法以在主应用程序中选择该通信方法。
在操作系统方面，您必须使用代码管理与设备通信的低级细节，因为这些细节通常取决于连接类型，我看不到通过尝试强制连接管理有任何好处以某种方式进入操作系统，这只会使管理复杂化。通过守护“通信管理器”并分离应用程序的其余部分以简单地查看或处理收集的数据，您可能会发现一些好处。
我不明白您会如何期望应用程序端的任何架构会以某种方式创建设备不需要更新以通过新协议报告的情况，例如 SMTP 合规性，绝对需要新的设备上的代码。
【讨论】：
我也对这个问题感到困惑；你能更精确（和简洁）吗？
我要说的一个评论是，您可能会考虑在串行端口/调制解调器通道上实现 PPP，以便始终使用 TCP/IP，并允许通过所有通道进行多个连接。
【讨论】：