请教windows service 与客户端 软件设计思路

[HenryWang99888]

我想做的程序包含三个部分，一个window service ，两个winform 客户端程序（均运行在同一台电脑上），实现的功能如下：
1.windows service 负责从设备接收TCP数据包，生成一个<设备对象>，数据包很多，对象的属性实时变化;
2.两个winform程序功能划分不同，但均靠调用windows service 中的方法，执行设备控制命令 或 查询设备状态

目前 我想使用的是socket方式接收数据包，那么问题来了：
1.winform程序有没有办法 像使用本地对象那样 直接调用 windows service 中<设备对象>的属性 和方法？ （因为windows service 中的对象比较大，访问频繁，用序列化 传参的方式比较慢）

2.winform程序 与 windows service之间用哪种通讯方式比较合理？ socket ? wcf? 窗体间消息 ？或者其它？

3. 当windows service 出现故障或 电脑死机时，设备如何第一时间知道，停机，采用什么方法比较合理 ？

4. 当winform 开启并在某界面下，windows service 会主动发送一些实时信息给 winform 显示，未开启时不发送，以减少通讯压力，这个如何实现？


希望 高手不吝赐教，多给宝贵意见 或者有这类的例子推荐一下

[以专业开发人员为伍]

跨进程，就要序列化。特别是一个service通常是为千奇百怪的客户端而设计的，尤其要序列化。但是设计一个service，不是纠结其什么数据库、底层实体。一个service的协议的设计要根据客户端的需求来设计。例如某个service可以返回当前一分钟内所有股票的几十个指标信息，但是假如某个客户端应用只需要几种股票的3、4个指标的信息，怎么办？当然是要设计一个适合这个需求的service功能服务啊！难道还要纠结原来有什么又大又慢的服务“已经包含了信息”么？你的思路是从底层出发的，而不是从应用出发。这就造成了本末倒置的许多争吵。 windows系统下的跨进程通讯可以有许多种，例如tcp、udp、管道、共享内存、msmq等等。前三者基本上跟你已经实现的差不多，所以你最好还是在自己的程序内部找找“效率”问题，例如是不是序列化方式不好、或者选择的承载方式效率低、或者是某个代码耗费了大量无效时间，等等。先用自己熟悉的方式来实现效率提升。 要知道service崩溃了，就需要有一个守护进程来定时监视一下。但是不关你是使用windows service，还是windows的“计划任务”，在配置画面其实你都能看到有关于“如果进程失败，如何处理”的设置。甚至你可以设置第一次、连续第二次、连续第三次崩溃时不同的处理方法“。也就是说，windows的服务或者计划任务，都帮你守护了你的进程。关键是你要懂得去用它。而其实最重要地，是你开发过程中经过了几十万次测试，随时进行测试，你的程序比较稳定，这时候再用这些措施其实才够格。 对于 tcp 长连接，它本身就是双向通讯的。这就好像腾讯有几十万服务器，几亿用户，当有信息时就会立刻把信息推送给用户的客户端，而不是等着海量用户去轮询服务器。当你的客户端访问服务器的时候，那么就建立一个连接，这个链接不断掉，这个连接的 TcpClient对象（或者Socket对象）保存在服务器端，当服务器有事儿要通知的时候就像客户端发信息就是了！而当客户端断掉了，发信息时自然就会异常，服务器端就知道断掉了（业务的心跳检测也是如此）。而如果客户端根本没有连服务器，自然从服务器端内存对象集合也就查找不到对应客户端ID的通讯对象。这个设计其实很简单。

[threenewbee]

直接用wcf，不要重复造轮子。