關於這種架構思想的來源，筆者長期做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的統一設想，電子病歷系統軟體可以劃分為以下幾個部分：

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之類的條條框框。怎麼適合需求就怎麼做，靈活變幻開發策略，以最優的路徑做出符合客戶需求的軟體。