2010-03-15 32 views
2

我正在构建一个将与嵌入式设备通信的.net应用程序(xp,vista,7)。我将能够通过IP,串口和调制解调器进行连接。 问题:我应该在应用程序中允许某种类型的开放连接,以允许我通过可能在操作系统中设置的其他一些渠道连接到该设备,以允许将来的扩展性,而无需在设备上进行任何更改?我只是想象,操作系统可以为所有可能通过操作系统设置到设备的通信渠道提供服务。就像管理员通过SMTP或其他协议设置某个频道一样。 我只是不想把自己放在一边,忽略一些更开放的架构。通过Windows和.Net连接到嵌入式设备

谢谢。

回答

2

我会说:不。

原因1:不要设计你不需要的功能。

原因2:如果另一个系统需要访问,它可以使用TCP或通过分离器的串行端口。不确定调制解调器有什么可能。类似的功能将很难实现,并得到自己的权利。

+0

+1:不要设计你不需要的功能。 – 2010-03-18 17:09:14

0

我对你的问题有点困惑,但我认为认为是你应该从应用程序中的高级代码中隔离通信方法。

答案是肯定的,在您的应用程序中创建一个抽象层,并通过您需要的任何方式(调制解调器,IP,串行,无论)来处理与设备的通信。这可能是通过定义一个支持所需通信调用的接口创建的,然后创建实现该接口的类来完成所选通信方法所需的工作。通过这种方式,除了必须选择一种通信方法外,您的更高级别的代码并不关心使用哪种通信方法

通过使用这种方法,它很容易将通信方法添加到软件中。根据设备的操作编写执行通信脏操作的类,并添加一些方法在主应用程序中选择该通信方法。

在操作系统正面,您必须拥有管理与设备通信的底层细节的代码,并且这些细节通常取决于连接类型,因为尝试强制连接时看不到任何收益以某种方式管理操作系统,这只会使管理复杂化。您可以通过守护“通信管理器”并分离其他应用程序以简单查看或处理收集的数据来获得某些收益。

我不明白你会期望应用程序端的任何体系结构会以某种方式创建一种设备不需要更新来通过新协议进行报告的情况,例如,SMTP合规性就绝对会要求设备上的新代码。

0

我也对这个问题感到困惑;你能更精确(和简洁)吗?

一个评论我要提出的是,你可能会考虑对串口/调制解调器频道的PPP的实施,使TCP/IP用于整个并允许通过各种渠道多个连接。