连接到带有 Windows 和 .Net 的嵌入式设备
我正在构建一个 .net 应用程序（xp、vista、7），它将与嵌入式设备进行通信。我将能够通过 IP、串行端口和调制解调器进行连接。 问题：我是否应该在我的应用程序中允许某种类型的开放连接，以便我可以通过操作系统中设置的其他一些通道连接到设备，以允许将来的可扩展性，而无需真正更改设备上的任何内容？我只是想象操作系统将能够为通过操作系统设置到设备的所有通信通道提供服务。就像管理员通过 SMTP 或其他协议设置某个通道一样。 我只是不想把自己限制在里面而忽略一些更开放的架构。
谢谢。
I am building a .net application(xp, vista, 7) that will communicate with an embedded device. I will be able to connect via IP, serial port and modem.
Question: Should I allow some type of open connection within my application that will allow me to connect to the device through some other channels that may be set up in the operating system just to allow future extensibility without really having to change anything on the device? I was just imagining that the operating system would be able to serve all communication channels that may be setup through the operating system to the device. Like would an admin setup some channel through SMTP or other protocol.
I just didn’t want to box myself in and ignore some more open architecture.
Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我想说：不。
原因一：不要设计不需要的功能。
原因2：如果另一个系统需要访问，可以使用TCP，或者通过分离器使用串行端口。不确定调制解调器可以做什么。类似的功能很难自己实现和正确实现。
I would say: No.
Reason 1: Don't design features you don't need.
Reason 2: If another system needs access, it can use TCP, or the Serial Port through a splitter. Not sure what is possible with a modem. Similar functionality would be quite hard to implement and get right yourself.
我对你的问题有点困惑，但我认为你的意思是，你应该将通信方法与应用程序中的更高级别代码隔离开来。
答案是肯定的，在您的应用程序中创建一个抽象层，并让该层通过您需要的任何方式（调制解调器、IP、串行等）处理与设备的通信。最好的创建方式可能是定义一个支持所需通信调用的接口，然后创建实现该接口的类，该接口完成所选通信方法所需的工作。这样，您的更高级别的代码并不关心使用哪种通信方法，而只需要选择一种方法。
通过使用这种方法，可以很容易地向软件添加通信方法。编写根据设备操作执行通信脏工作的类，并添加一些方法来在主应用程序中选择该通信方法。
在操作系统方面，您必须使用代码来管理与设备通信的低级详细信息，并且由于这些详细信息通常取决于连接类型，因此尝试将连接管理强制纳入操作系统并没有看到任何好处不知何故，这只会使管理变得复杂。通过守护“通信管理器”并分离应用程序的其余部分以简单地查看或处理收集的数据，您可能会发现一些好处。
我不明白您如何期望应用程序端的任何架构会以某种方式创建一种情况，即设备不需要更新即可通过新协议进行报告，例如 SMTP 合规性，绝对需要在设备。
I'm a bit confused on your question but what I think your getting at is that should you isolate communication method from the higher level code in your application.
The answer to that is yes, create an abstraction layer within your application and have that layer deal with communication to the device by whatever means you need (modem, IP, serial, whatever). This is probably best created by defining an interface that supports your needed communication calls and then create classes that implement that interface which do the work needed by the chosen communication method. This way your higher level code doesn't care what communication method is used other than having to choose one.
By using this method its rather easy to add communication methods to the software. Write the class that does the communication dirty work based on the operation of your device and add some method to select that communication method in the main application.
On the operating system front you will have to have code managing the low level details of communication to the device and as these details are very often dependent on the type of connection i don't see any gain by attempting to force connection management into the OS somehow, this just complicates administration. You may find some gain by daemonizing a "communication manager" and separating the rest of your application to simply view or process the data collected.
I don't get how you would expect any architecture on the application end would somehow create a situation where the device doesn't need to be updated to report via a new protocol as SMTP compliance, for example, absolutely would require new code on the device.
我也对这个问题感到困惑；你能更精确（和简洁）吗？
我要提出的一个意见是，您可能会考虑在串行端口/调制解调器通道上实现 PPP，以便始终使用 TCP/IP，并允许通过所有通道进行多个连接。
I too am confused by the question; can you be more precise (and succinct)?
One comment I would make is that you might consider a PPP implementation on the serial port/modem channels, so that TCP/IP is used throughout and will allow multiple connections through all channels.