电子病历系统到底采用B/S还是C/S架构，是一个长期争论的话题。而在业界，两种架构的应用范围谁也不占有显著优势。在此，笔者提出一种B/S和C/S混合的架构，以下是其原理图。

B/S和C/S混合架构原理图

在该架构中，主要包括如下几个部分：

1.Web服务器

这是系统的核心。大多数的业务流程运行在Web服务器中。采用ASP.NET开发，直连数据库。

Web服务器包含系统功能 API集合，以远程调用的方式向PC客户端软件提供功能支持。

还包含ASPX页面，向移动设备提供功能支持。

2.PC机客户端

PC机客户端为一个轻量级的客户端软件，为一个.NET开发的WinForm软件。该软件提供良好的互换性操作体验，提供各种病历数据的查看、录入和打印功能。大多数情况下本软件只进行简单的数据转发功能，基本上不执行具体的业务流程操作。

3.移动设备

移动设备采用浏览器形式访问Web服务器。

4.数据库服务器

为一个专门的数据库服务器，只向Web服务器开放连接。

以下是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的理解可以如下：

两者逻辑上的高度相似性可以很容易联想到物理学中引力和电磁力逻辑上的高度相似性。物理学中正在谋求统一场理论，那么我们也可以谋求B/S和C/S的统一。

虽然B/S和C/S呈现用户界面的代码虽然语言不同、代码执行的地方不同，但逻辑是相同的，因此逻辑上完全可以统一起来。以此类推，对于业务逻辑执行也是这样的，这就是B/S和C/S统一的理论基础，具体表现形式可以是OOP、AOP之类的。

重新解读电子病历系统软件

按照B/S、C/S的统一设想，电子病历系统软件可以划分为以下5个部分：

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的，这样软件具有强大的扩展性和生命力。

回归到笔者的老本行，电子病历编辑器。编辑器控件提供WinForm版本和ASP.NET版本的。WinForm版本支持所有的功能；不过受限于当前技术水平，ASP.NET版本只能只读的阅读病历文档内容，而无法编辑修改。因此建议在开发常规电子病历系统时采用C/S模式，对于互联网应用，比如公卫平台之类的，也是建议新的B/S和C/S统一模式。对于移动应用可以采用传统B/S模式。

最后总结一下，《孙子兵法》说了：兵势如水；小平同志的白猫黑猫也是这个理。笔者觉得，开发软件也应该“兵势如水”，不必拘泥于B/S、C/S之类的条条框框。怎么适合需求就怎么做，灵活变幻开发策略，以最优的路径做出符合客户需求的软件。