袁永福--南京都昌信息科技有限公司創始人

前幾天下午去開發醫療軟件的S公司，旁聽了他們的內部技術討論會議。他們目前的電子病歷是B/S架構，會上一群人討論起用C/S重構電子病歷系統的可行性，于是引出了本文的題目：電子病歷，到底是用B/S還是C/S。

電子病歷，到底是用BS還是CS

袁永福

2014-8-19

      前言：前幾天下午去開發醫療軟件的S公司，旁聽了他們的內部技術討論會議。他們目前的電子病歷是B/S架構，會上一群人討論起用C/S重構電子病歷系統的可行性，于是引出了本文的題目：電子病歷，到底是用B/S還是C/S。

     電子病歷等醫療信息化系統到底是用B/S模式還是C/S模式。這是一個長期以來困擾著許多甲方和乙方的基礎性的技術問題。過去困擾了，現在還在困擾，估計將來還會困擾。

     這個問題真的是可以花開兩朵，各表一枝了。首先說說B/S模式。

     B/S模式最為稱贊的特點就是部署、維護和升級非常方便，這是一個無與倫比的優點，一俊遮百丑的優勢，網絡上到處都有歌功頌德的帖子，我內心也是真心認同和贊揚的。很多時候，你若BS，便是晴天。

     對于軟件開發來說，B/S還有一個好處程序功能模塊化。要加個功能，也就新增一個WEB頁面，寫上服務器端代碼，這個操作對已有模塊沒有任何影響。因此比較容易做出層次明晰，結構合理，[袁永福原創]能持續可控變化的系統。

     得益于傳奇的Macromedia公司和強大的ADOBE公司，B/S的靜態UI展示功能非常好；而隨著技術不斷發展，B/S的動態UI展示功能也在逐漸增強，比如http://fineui.com就是一個很好的例子。

     孫子兵法云：“不知兵之害者，不能盡用兵之利”。同樣的，不知技術之害者不能盡用技術之利。對于電子病歷等醫療信息化系統來說，B/S還是有著明顯的缺陷，此時C/S程序仍然具有相當的優勢。在此進行對比。

>>頁面狀態

     由于B/S的基礎的HTTP協議的無狀態的特性。使得B/S中各個頁面數據交換比較困難，數據交換過度依賴數據庫，大多數狀態數據都需要反復的保存和讀取數據庫，增加不少代碼量。醫療業務流程中的業務數據鏈路密集復雜，使用B/S處理起來還是很費勁的，相信廣大程序猿深有體會。

     對于來說C/S程序各個窗體之間交換數據很方便，窗體之間的函數、屬性和事件可以自由的相互調用，能比較簡潔優雅的處理業務數據路由。

>>離線運行能力

     B/S程序基本上沒有離線運行能力，所有操作都必須在線執行，中途斷線了，則頁面上的數據全部丟失，用戶體驗非常的不好。相信大家都曾經遇到過，比如敲字發帖或者發電子郵件，辛辛苦苦敲了幾百個字，一提交時才發現網絡斷了或者服務器當機了，文字全部丟失，肯定會抓狂的。

     而C/S 程序具有離線運行能力，[袁永福原創]當網絡或者服務器不可用時，可以將用戶輸入的數據暫存在內存或者臨時文件中，等到網絡環境好了再上傳，這樣比B/S程序大大改善用戶體驗。

>>瀏覽器兼容性問題

     瀏覽器兼容性問題是B/S程序的老大難問題，過去頭疼，現在頭疼，未來還是會頭痛的。相同的頁面，在不同公司的瀏覽器或者同種瀏覽器中的各個版本之間存在一定的顯示差距。比如在設計時“保存”按鈕放在最下面，對于IE8能顯示，而對于IE7就不顯示，使得應用系統不可用。

     規定客戶使用指定版本的瀏覽器也是不可靠的。客戶可能會運行多家公司的軟件產品，各家公司期望指定的瀏覽器版本可能不一樣，此時會產生沖突，讓一家適應另一家都是比較痛苦的過程。

     而C/S程序就沒有這種瀏覽器兼容性問題，而且一樣的程序，對于不同版本的Windows系統，其界面也差不多，都是能用的。

>>IE嵌控件

     醫療軟件中一些用戶體驗使用JS/DHTML實在做不出來，于是采用IE嵌控件的形式，最常見的就是電子病歷編輯器控件。

     所有的IE嵌控件技術都是不大穩定的，需要配置瀏覽器的安全性設置、需要設置客戶端控件的更新配置，可能存在少數電腦就是無法自動更新控件，需要手動進行更新，而且各種IE插件間會相互影響，[袁永福原創]還會受到360等安全軟件的影響。此時B/S系統喪失了部署簡單更新方便的優點了。

在這種情況下，還不如使用C/S程序來做。

>>本地數據緩存

     希臘神話中，西西弗斯因為在天庭犯了法，被大神懲罰，降到人世間來受苦。對他的懲罰是：要推一塊石頭上山。每天，西西弗斯都費了很大的勁把那塊石頭推到山頂，然后回家休息，但到了晚上石頭又會自動地滾下來，于是，第二天又要把那塊石頭往山上推。這樣，西西弗斯所面臨的是永無止境的推石頭。

     我們的B/S程序有時候就是西西弗斯在重復又重復的推石頭。醫療軟件在使用的時候需要調用很多字典類型的數據，比如庫存藥品清單、ICD編碼、各種醫學技術名詞、可用的知識庫等等，這些數據記錄都是成千上萬的，可是B/S頁面無法本地數據緩存，每次刷新頁面都需要重新加載這些字典數據，增加服務器的負荷，影響軟件的響應速度，即使采用JS動態加載，也只是治標不治本的。JS無法進行本地數據緩存，因為JS沒有訪問本地文件系統的權限。

     而C/S程序可以很方便的進行本地數據緩存，而且事實上筆者見過的所有的C/S醫療軟件在啟動的時候都會花上一段時間來加載各種字典數據，這樣在運行中就直接使用本地緩存的數據，這能提高程序的響應數據，降低服務器的工作量。

>>軟件自動升級

     B/S程序最大的優點就是部署、實施和更新升級很方便。

     C/S雖然這方面差一些，但隨著技術的進步，這方面也在逐漸改善。筆者認為在現在的技術條件下，C/S軟件的自動安裝和自動升級真覺得不是問題。這點網絡上泛濫成災的流氓軟件就是很好的證明。再比如QQ客戶端軟件，幾乎每臺電腦都會安裝，也很好的解決了部署升級問題。

現在客戶端絕大多數還是微軟的Windows系統，微軟針對軟件的部署和升級提供了很多底層的支持，包括SmartClient/ClickOne技術等等，[袁永福原創]這些都為C/S軟件的自動化部署升級帶來很大便利。

>>運行性能

     現在的B/S程序大量依賴JS技術。而JS語言是解釋方式運行的，很靈活，但容易出錯，而且運行速度慢。當JS太多時，比如前頭提到的S公司，他們的JS代碼量占40%，此時瀏覽器經常報JS運行超時的警告信息。

     而C/S程序都采用編譯性語言，會進行嚴格的語法檢查、很多錯誤都在開發編譯階段能發現，這能提高代碼的運行速度。即使遇到耗時的操作，也可以使用多線程操作來改善用戶體驗。

>>代碼規范

     B/S程序的客戶端編程語言是JS，JS是面向對象的，單不是基于對象的，而且很多公司重視程序代碼的質量，但不大重視JS的代碼質量，因此造成JS代碼的臃腫，出現大量的重復代碼。

     相對來說主流開發組織對C/S的編程語言是講究規范的，比如C#/JAVA等，還有專門的語言規范檢查工具，而且C/S的編程語言大多是完全的面向對象的，能很好的實現代碼重用，重構也很方便。[袁永福原創]主流開發組織也重視代碼庫的積累和維護。

>>國際化

     所謂國際化就是推出軟件的多語言版本。比如電子病歷系統的簡體中文版、繁體中文版、維文版、英文版之類的。

     目前中國國內的醫療軟件產品基本上不考慮國際化。不過有條件的公司應該還是要考慮到軟件產品國際化。

     B/S軟件比較難于做到軟件的國際化，因為WEB頁面中的文字都硬編碼在HTML代碼中，同時維護WEB頁面的多語言版本工作量很大，而且JS/DHTML比較難于實現字符串資源的各個版本。

     相對來說，C/S程序比較容易實現軟件的國際化。比如對于VS.NET的WinForm窗體，可以在設計階段來配置多語言版本的資源文件。例如下圖所示：

                       

     這是VS.NET中一個WinForm窗體的相關文件。在這里dlgSpecifyPaste.ar.resx是維文版的資源文件，dlgSpecifyPaste.en.resx是英文版的資源文件，dlgSpecifyPaste.resx是默認的簡體中文版的資源文件，dlgSpecifyPaste.zh-TW.resx是繁體中文版的資源文件。

     使用這些資源文件，[袁永福原創]可以讓窗體在不用的語言環境下顯示不同語言版本的內容，不過都表達相同的意思。

     編碼中需要的字符串也可以另外放在資源文件中方便的實現多語言版本。這樣編譯結果就是一個主程序配上多個語言版本的資源文件。比較輕松的實現了國際化。

>>用戶行為
    一些用戶行為在B/S中沒法很好的處理。最常見的就是直接關閉瀏覽器。一些瀏覽器提供窗口關閉事件，JS可以響應這個事件來進行處理，不過這存在瀏覽器兼容性問題，可能在某些情況某些瀏覽器中JS無法響應這個事件。
    另外就是彈出窗口功能了。瀏覽器可能會阻止彈出式的窗口。在彈出式的窗口中的JS效果和普通窗體中的JS效果還可能不一樣。這些就是需要花不少時間調試和配置的。
而對于C/S程序就沒有這種問題了。

     從上面分析可以看出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的，這樣軟件具有強大的擴展性和生命力。

     回歸到筆者的老本行，電子病歷編輯器。編輯器控件提供WinForm版本和ASP.NET版本的。WinForm版本支持所有的功能；不過受限于當前技術水平，ASP.NET版本只能只讀的閱讀病歷文檔內容，而無法編輯修改。因此建議在開發常規電子病歷系統時采用C/S模式，對于互聯網應用，比如公衛平臺之類的，也是建議新的B/S和C/S統一模式。對于移動應用可以采用傳統B/S模式。

     最后想總結一下，[袁永福原創]孫子兵法又說了：兵勢如水。小平同志的白貓黑貓也是這個理。筆者覺得開發軟件也應該“兵勢如水”，不必拘泥于B/S,C/S之類的條條框框。怎么適合需求就怎么做，靈活變幻開發策略，以最優的路徑做出符合客戶需求的軟件。

【作者簡介：袁永福，微軟MVP，資深軟件開發專家，著書立作，就職于南京都昌信息科技有限公司（http://www.dcwriter.cn），現從事于電子病歷編輯器、時間軸等醫療用軟件組件的研發工作。博客網址http://www.rzrgm.cn/xdesigner。】