HIT专家网
来源：HIT专家网 作者：南京都昌信息科技有限公司 袁永福
电子病历等医疗信息化软件到底选择用B/S模式，还是C/S模式？这是一个长期以来困扰着许多甲方和乙方的基础性技术问题。过去困扰了，现在困扰着，估计将来还会困扰。现在有一种技术流派，想要超越B/S和C/S之争的，做出结合B/S和C/S两者优点的混合模式。本文就说说这种混合模式。
软件架构的本质
笔者长期从事UI层开发，那么就从UI层开始说起。
现在大多数医疗软件都是图形化用户界面，对于C/S程序，写C#代码调用DrawString()、DrawLine()、DrawImage()之类的GUI API来绘制用户界面；而对于B/S程序，是服务器端写代码输出HTML代码，然后发给浏览器让其解释这个HTML代码来“绘制”用户界面。
因此可以抽象出来看，程序猿都是花大量的代码来绘制图形化用户界面，只不过一部分代码输出图形绘制指令，一部分代码输出HTML代码。但最终目的都是一样的。
另外，程序猿还需要写大量的代码来让图形化用户界面和用户互动，都需要响应KeyDown/MouseClick等事件。这点大家写的代码都很类似，最终目标也一样。
按照这种思想，B/S和C/S的理解可以如下：
- C/S程序：数据库服务器→应用软件→界面呈现信息（DrawString等指令）→GUI（For Windows）
- B/S程序：数据库服务器→应用软件→界面呈现信息（HTML代码）→GUI（For Browser）
两者逻辑上的高度相似性可以很容易联想到物理学中引力场和电磁场逻辑上的高度相似性。物理学家们正在谋求统一场理论，那么我们也可以谋求B/S和C/S的统一。
因此，B/S和C/S呈现用户界面的代码虽然语言不同、代码执行的地方不同，但逻辑是相同的，因此逻辑上完全可以统一起来。以此类推，对于业务逻辑执行也是这样的，这就是B/S和C/S统一的理论基础，具体表现形式可以是OOP、AOP之类的。
按照B/S和C/S的统一理论，大多数应用软件可以划分为以下几个部分：
（1）数据库服务器。SQL Server、Oracle、NOSQL之类的。
（2）业务逻辑执行层。执行医疗业务逻辑的代码，这个层面纯粹执行业务功能，没有用户界面。而且考虑到B/S应用应该是多线程安全的。
（3）B/S服务器应用层。运行在Web服务器上的，直接调用业务逻辑执行层来实现业务功能。
（4）远程调用包装层。对业务逻辑层执行层的功能进行包装，能方便的进行远程调用，这个远程调用就是基于XML的WebService或者基于二进制的JAVA/.NET Remoting。
（5）C/S客户端软件。客户端软件通过网络调用远程调用包装层来执行业务逻辑。
对于这种架构模型，如果业务逻辑执行层和B/S服务器应用层编译在一起就是传统的B/S系统；业务逻辑执行层和C/S客户端软件编译在一起就是传统的C/S系统。如果5个部分都分开，那么就是同时支持B/S和C/S的，这样的软件具有强大的扩展性和生命力。
因此建议在开发常规电子病历系统时采用C/S模式；对于互联网应用，比如公卫平台之类的，也是建议新的B/S和C/S统一模式；对于移动应用可以采用传统B/S模式。
最后总结一下，《孙子兵法》说：兵势如水。小平同志的“白猫黑猫”也是这个理。笔者觉得，开发软件也应该“兵势如水”，不必拘泥于B/S、C/S之类的条条框框，怎么适合需求就怎么做，灵活变幻开发策略，以最优的路径做出符合客户需求的软件。
B/S和C/S混合模式
下表是B/S、C/S和混合模式在院内局域网环境下的各项评分情况：
| 编号 | 对比项目 | 满分 | B/S | B/S得分 | C/S | C/S得分 | B/S和C/S结合的混合模式 | 混合模式得分 | 说明 |
| 1 | 离线运行能力 | 3 | 无，若系统突然断网、服务器崩溃，数据全部丢失。 | 0 | 有，若系统突然断网，数据可以缓存到本地，联网后再保存。 | 3 | 有 | 2 | 用户辛苦敲入大段文本，突然断网了，心情不会好的。 |
| 2 | 页面状态数据 | 1 | 全靠ASP.NET SESSION，编程比较复杂。 | 0.5 | 控制简单，几个全局变量即可完成。 | 1 | 控制简单 | 1 | |
| 3 | 页面间数据传输 | 1 | 全靠ASP.NET SESSION，编程复杂而且效率低。 | 0.5 | 简单，全局变量，公开的属性或字段就能实现该功能。 | 1 | 简单 | 1 | |
| 4 | 浏览器兼容性问题 | 3 | 有，增加开发和维护难度和工作量。 | 0 | 无 | 3 | 无 | 3 | 严格限制客户端浏览器版本是一种不友好的行为，有时候会和其他软件发生冲突。应当尽量避免。 |
| 5 | 本地数据缓存 | 1.5 | 无，如果系统配置了知识库列表，药品信息列表，ICD数据列表，则需要频繁的重复下载。 | 0 | 有。无需频繁的重复下载。减少网络IO负荷和对服务器的依赖。 | 1.5 | 有 | 1.5 | |
| 6 | 软件升级 | 8 | 简单，只要更新服务器软件即可。 | 8 | 必须要更新客户端软件，次数多，成本高，影响系统运行。 | 2 | 大部分情况下更新服务器即可。少数情况下才需要更新客户端软件。 | 6 | 目前的各种自动更新技术应该是够用的，而且电子病历是院内系统，有一定的控制力度。另外应该是以用户使用方便为第一，开发和维护人员自己方便为第二。 |
| 7 | 系统配置更改 | 2 | 简单 | 2 | 复杂 | 0 | 简单 | 1.5 | 比如数据库服务器换IP了。防火墙修改了。 |
| 8 | 运行速度 | 4 | 慢。网络传输速度和客户端浏览器呈现速度比较慢，一般操作都需要几秒钟的时间。 | 2 | 快，主要受限于网络传输速度。 | 4 | 快，主要受限于网络传输速度。 | 4 | 对于BS软件，可能服务器端运行耗时只有几百毫秒，但在网络传输和浏览器展现页面需要耗掉几千毫秒。 |
| 9 | 网络带宽利用效率 | 1 | 低，一般为明文原始格式传输 | 0 | 高，可以加密压缩传输。 | 1 | 高。 | 1 | |
| 10 | 用户互操作体验 | 6 | 一般。 | 2 | 良好 | 6 | 良好 | 6 | 用户年复一年的操作这些界面，稍微减少些鼠标键盘操作就能产生显著的效益。另外一些病历模板工具等软件模块基本上只能用CS模式。 |
| 11 | 安全性 | 1 | 高。服务器软件控制好就行了。 | 1 | 低。 | 0.5 | 高。基本上等于服务器的安全性。 | 0.5 | 由于是院内系统，行政管理能帮助进行安全管理。 |
| 12 | 部署 | 5 | 简单。但是如果不得不出现IE嵌控件的形式，则很复杂。 | 4 | 复杂，需要配置客户端运行环境，配置数据库连接信息。 | 0 | 比较复杂。但无需配置数据库连接信息。 | 3 | 可能要用上医保接口，容易出现IE嵌控件的情况。 |
| 13 | U盘,K宝等外接设备 | 2 | 复杂，需要仔细配置客户端运行环境，容易出错。 | 0 | 简单 | 2 | 简单 | 2 | 比如用上电子签章功能，医生人手一个K宝。 |
| 14 | 打印 | 2 | 难于做到精细打印。比如不弹出对话框的打印，指定打印机、纸盒，续打，双面打印等。 | 0.5 | 简单强大 | 2 | 简单强大 | 2 | |
| 15 | 开发技术 | 4 | 复杂。需要C#/HTML/JS的混合编程。对开发人员要求高。调试操作复杂。 | 1 | 简单，统一的WinForm编程模式。 | 4 | 较为简单，ASP.NET和WinForm编程，编程语言统一。 | 2 | 开发人才难找，需要降低对开发人员的要求。 |
| 16 | 产品化 | 1 | 复杂。 | 0.5 | 简单，可以方便的制作安装文件和各种配置工具。 | 1 | 比较复杂。 | 0.5 | 既然以后要向其他医院推广，需要考虑到软件的产品化。 |
| 17 | 数据库负载 | 4 | 良好 | 4 | 差，需要创建大量数据库连接。 | 0 | 良好，不直连数据库。 | 4 | |
| 18 | 灾难恢复 | 5 | 差，服务器宕机，所有客户端都不能用。 | 0 | 有一定的应付能力。部分数据可以暂存本地。 | 3 | 有比较弱的应付能力。 | 1 | 电子病历应该是7X24小时运行的系统。 |
| 19 | 对移动设备的支持 | 4 | 良好 | 4 | 无 | 0 | 良好，仍然提供WEB页面功能。 | 3 | |
| 20 | 并发控制 | 1 | 好 | 1 | 一般 | 0.5 | 好 | 1 | |
| 21 | 系统伸缩性 | 1 | 好 | 1 | 差 | 0 | 好 | 1 | 医院职工数比较稳定。 |
| 22 | 系统可扩展性 | 7 | 好 | 7 | 差 | 2 | 较好 | 5 | 医疗需求变更比较大，会比较频繁的调整的系统功能，对系统可扩展性要求比较高。 |
| 23 | 客户端硬件要求 | 4 | 要求低 | 4 | 有一定的要求 | 1 | 要求比较低 | 2 | |
| 24 | 服务器端硬件要求 | 1 | 要求高 | 0 | 要求低 | 1 | 要求比较高 | 0.5 | |
| 25 | 操作系统底层功能调用 | 5 | 无，HTML/JS权限很低。 | 1 | 有 | 5 | 有 | 5 | 某些情况下需要调用操作系统底层功能。比如不同病人的病历文本不能相互复制就需要直接访问系统剪切板。自动安装和配置医保接口之类的。 |
| 26 | 国际化（多语言版本） | 0.5 | 复杂 | 0 | 简单 | 0.5 | 简单 | 0.5 | 比如开发繁体中文版，英文版等等。 |
| 27 | 代码管理 | 4 | HTML夹杂JS，代码管理不便。 | 1 | 统一的编程语言，有VSS/SVN等专业代码管理工具。 | 4 | 简单 | 4 | 代码管理方便则软件可以持续发展，人员接替方便。 |
| 总分 | 82 | B/S得分 | 45 | C/S得分 | 49 | 混合模式得分 | 64 |
从上表可以看出，在院内局域网运行环境中，B/S、C/S混合模式还是有着明显优势的。
改进混合模式
但是在实践中，这种B/S、C/S混合模式还是不够实用，主要原因是：
1.已经存在一些B/S系统。这些系统凝聚了客户投资，得到的广泛应用，应该得到持续的利用。
2.WebService还是比较复杂的开发手段，难于普及。大量的中低级程序员还是习惯传统的B/S开发模式。这些开发力量应该产能最大化。
于是上面的B/S和C/S的混合模式应该进一步改进来降低实现难度。为此设计出如下图的软件架构：
在这种模式下，存在一个客户端EXE程序，比如用C#或者DELPHI开发，然后内嵌一个Chrome或者IE浏览器内核；同时内嵌其他的需要和用户高度互动的软件组件，比如病历编辑器控件；还有一些需要平台调用的组件，比如医保组件，特定外接硬件设备的访问接口程序等等。
此时大多数业务功能是以网页的形式展示在客户端的浏览器内核，只有在必要的情况下才通知客户端程序来运行本地组件。这样有以下好处：
（1）能比较充分利用现有的传统的Web开发能力。无需编写大量的WebServe等Web接口。
（2）能充分利用现有的B/S软件的功能。现有Web页面无需大量改造即可使用客户端浏览器内核来显示。
（3）能解决客户端配置问题。现实当中由于存在客户端医保接口组件等类似的原因。客户端电脑仍然需要进行很多手工安装配置工作。此时B/S系统便于部署和更新的优势大打折扣。而采用客户端程序，可以实现客户端软件组件的自动更新和部署。
【小结】
B/S和C/S技术路线各自有着明显的优势，适用于不同的应用场景，不能简单地评判优劣。作为优秀的工程技术人员不应该将两者严格分隔开来，而是结合两者，扬长避短，才能更好地解决实际问题。而本文提出的B/S和C/S混合技术方案是一种在很多应用场景中值得考虑的技术方案，希望能给各位读者带来启发。
【作者简介】
袁永福，南京东南大学毕业，微软MVP，南京都昌信息科技有限公司创始人，长期从事电子病历编辑器控件的研发和推广工作，其产品成为编辑器细分市场的主要品牌。（邮箱：28348092@qq.com）
【责任编辑：谭啸】
评论前必须登录！
注册