使用存儲工廠構建區域協同醫療信息系統遇到的問題及解決方法

于冬

內蒙古巴彥淖爾市醫院 計算機中心，內蒙古 巴彥淖爾 015000

使用存儲工廠構建區域協同醫療信息系統遇到的問題及解決方法

于冬

內蒙古巴彥淖爾市醫院 計算機中心，內蒙古 巴彥淖爾 015000

在我國新醫改不斷推進的大環境下，區域協同醫療從未變得如此重要，而另一方面，醫院信息系統反而在最初就被設計成為一個孤立王國。本文全面描述了如何使用存儲工廠在醫院信息系統外面包裹一層數據訪問層，在二者之間形成一個堅實的紐帶促進它們的融合，并聚焦于該應用的很多特定場景，與同行分享解決這些棘手問題的經驗。

存儲工廠；區域協同醫療；醫院信息系統；數據訪問層

0 前言

隨著新醫改的不斷深入和發展，實現醫院間醫療資源與信息資源的整合共享越來越成為大勢所趨，而最初開發的醫院信息系統（HIS）基本是基于本醫院層面的，各自為政，從而產生了形形色色的信息孤島，導致無法實現醫院間的雙向轉診，最終導致重復醫療，重復檢查的情況，大大浪費了寶貴的醫療資源。近年來，區域協同醫療以區域為突破點，整合區域內各醫院層面的信息系統，通過衛生信息數據庫和信息平臺，在實現百姓就醫預約制、看病一卡制、病歷終身制上取得了長足的進步，為最終建立全社會的“公共服務信息平臺”進行了很多有意義的探索[1]。

為了適應區域協同醫療的需求，必須對現有封閉式的HIS進行改造，使其具有標準化的數據訪問接口以進行一致的數據交換。在軟件設計層面，必須引入經過驗證的、可重用的、可維護的、松耦合的應用軟件系統[2]。存儲工廠（Repository Factory）本身作為一個輕量級的代碼生成器，以自動化的方式從現有的數據模型創建業務實體，并生成數據訪問邏輯的存儲類和工廠以及數據庫服務器端的存儲過程，這是微軟模式與實踐小組推薦的在既有系統上構建標準化數據訪問接口的實現模式。

1 存儲工廠的作用和功能

存儲工廠不是一個對象-關系映射（Object-Relational Mapping，ORM）工具，它其實是一個輕量級的代碼生成器，主要作用和功能就是自動生成對現有數據庫訪問技術中最關鍵的領域模型對象（domain model object），并將其持久化為數據庫的任務代碼。這點表明它本身不是一個建模工具，而是在已經建立好的模型上額外構建一層標準的數據訪問接口，這就相當于HIS這個自由王國主動展示出歡迎外界來訪的姿態，而且規范了如何訪問的標準，所以存儲工廠非常適合我們在現有的HIS上進行改造，它對現用的舊有系統的使用不產生任何影響，而新開發的系統都將構建在這個標準的數據庫訪問層上，符合積累量變最后達到質變的軟件進化的觀點。

2 存儲工廠的使用

存儲工廠目前已經交由開源社區CodePlex進行開發，最新的版本Build31651可以從http://www.codeplex.com/RepositoryFactory這個主頁上下載[3]。下面我們將簡述存儲工廠的使用過程，具體內容大家可以參閱相關資料和網頁[4]。

2.1 啟用存儲工廠

我們使用的集成開發工具為Visual Studio 2008，具體操作步驟如下：

在“工具”菜單中選擇“Guidance Package Manager（向導包管理器）”打開向導包管理器，點擊“Enable/Disable Packages…(啟 用 /禁 用 向 導 包 …)”， 勾 選“Repository Factory MAR 2009（存儲工廠2009年3月發布版）”，點擊“確定”，啟用存儲工廠成功。

2.2 指定項目的責任

存儲工廠在生成代碼時將其內部按照功能不同劃分為3個項目層，分別為：業務實體項目、數據訪問項目、宿主項目，我們必須將解決方案中的項目映射到這3個項目層上，具體操作步驟如下：

在對應項目的右鍵菜單上，選擇“Specify project responsibility(指定項目職責)”,勾選對應的項目類型：Business Entities Project(業 務 實 體 項 目 )、Data Access Project(數據訪問項目)、Host Project(宿主項目)。

2.3 添加數據庫連接

存儲工廠可以為當前主流的企業級數據庫生成連接，包括SQL Server以及Oracle，具體的操作步驟如下：

在宿主項目的右鍵菜單上，選擇“Add SQL Server database connection(加入 SQL Server 數據庫連接 )”、“Add Oracle database connection(.NET Framework)(加 入Oracle數據庫連接—針對.NET架構)”、“Add Oracle database connection(ODP.NET)(加入 Oracle 數據庫連接—針對ODP.NET)”，輸入連接名和連接字符串。

2.4 創建實體類

存儲工廠將創建對應于數據庫中表的業務實體類，用于將數據表中的內容持久化到根據實體類模板創建的實體對象中，創建實體類的具體操作步驟如下：

在業務實體項目的右鍵菜單上，選擇“Create business entities from database(從數據庫中創建業務實體)”，選擇宿主工程中剛才創建的連接字符串進行數據庫連接，設置默認的命名空間，然后選擇表、視圖、字段，設置或者修改各個實體的屬性和數據類型，點擊完成后會自動生成業務實體的代碼。

2.5 創建CRUD存儲過程

存儲工廠將為我們創建對應數據庫訪問的CRUD（Create、Retrieve、Update、Delete）操作的存儲過程腳本，大大簡化了繁瑣枯燥的編碼工作，具體操作步驟如下：

在數據訪問項目的右鍵菜單上，選擇“Create CRUD Stored Procedures（創建CRUD存儲過程）”，選擇對應的數據表，存儲工廠可以創建Insert、Update、Delete、GetAll、GetOne、GetMany等6種類型的存儲過程。

2.6 創建數據存儲

存儲工廠將根據業務實體創建數據存儲類，其中，創建的很多方法是真正讓數據流動起來的載體，是存儲工廠所創建代碼的核心部分，具體操作步驟如下：

在數據訪問項目的右鍵菜單上，選擇“Create data repository classes from business entities（從業務實體中創建數據存儲類）”，選擇之前生成的業務實體，指定實體和存儲過程之間的映射關系，還可以進一步指定實體屬性和存儲過程參數之間的映射關系，點擊完成后將生成數據存儲的代碼，其中，包括Repository接口和實現以及分別針對每一種操作生成的一個工廠類。

2.7 使用生成的數據存儲和訪問代碼

我們現在可以創建存儲工廠類的一個實例對象來進行具體的數據訪問操作了，具體代碼如下：

3 實踐中遇到的難題與求解

有了這樣一個好的架構和開發工具，很多人都想當然地認為應用起來一定會一帆風順，其實不然，實踐中仍然存在著巨大的技術風險和陷阱。在使用這項新技術之前，我們首先對該技術進行了預研，即對該項創新技術通過集體智慧進行整體研判，然后通過精心設計的場景進行仿真模擬實驗，循序漸進地進行了多項集中公關，最終才確認了該創新技術應用的可行性及技術方案的準確性。下面是我們聚焦存儲工廠在實際開發中遇到的一些難題，與各位開發者分享我們的求解過程及最終的解決方案。

3.1 升級存儲工廠引用企業庫版本

存儲工廠本身建構在企業庫3.1的版本上面，但由于我們整體的解決方案（Solution）是建構在最新的企業庫4.1的版本上面，雖然.NET技術允許程序集(Assembly)不同版本同時存在，但是這樣會造成將來的軟件系統部署的復雜性，意味著在一個系統中必須同時部署企業庫3.1和4.1版本，而且要保證配置文件對程序集引用的正確性，在軟件設計和可維護性方面也將是易出錯的，一旦發生引用錯誤，往往會出現莫名其妙的結果，嚴重影響開發和維護人員對錯誤的判斷力和排除錯誤的效率[5]。

解決的辦法是：由于存儲工廠是開放源碼的，我們通過修改源碼，升級其引用企業庫的版本到4.1。我們將C: epositoryfactory-31651TrunkSourceLib目錄下的企業庫程序集Microsoft.Practices.EnterpriseLibrary.Common.dll Microsoft.Practices.EnterpriseLibrary.Configuration.Design.dll Microsoft.Practices.EnterpriseLibrary.Data.dll 升級到企業庫4.1版本的同名文件，Microsoft.Practices.ObjectBuilder.dll升級為企業庫4.1版Microsoft.Practices.ObjectBuilder2.dll。然后將解決方案LibrariesSchemaDiscoveryDbSchemaProviderFactory.cs文件中的語句using Microsoft.Practices.ObjectBuilder;改為using Microsoft.Practices.ObjectBuilder2;重新建立整個解決方案，升級成功。

3.2 返回數據庫生成新插入數據行的主鍵。

由于特定的數據表本身存在唯一性約束的要求，具體到現實業務中的一個例子就是在病員新入院時，我們需要根據特定的規則為該病員生成一個唯一標識，即所謂的住院號，為了保證這個標識不會重復，必須由數據庫端來生成，然后返回到前臺用于顯示、打印異或后續涉及該病員的其它業務。

解決的辦法是：存儲工廠本身預留了一個回調函數專門用來實現這個功能，只不過經常我們插入數據的時候并不需要返回該數據行的標識，因此視而不見。具體代碼如下：

3.3 刪除復合主鍵的數據行

對于刪除數據行的情況，存儲工廠已經為我們生成了類似 public void DeleteT_patientInfo(System.String patientId)這樣的函數，我們可以通過唯一的主鍵病員ID來刪除對應的病員記錄。但在一些更為復雜的情況下，如要刪除某個病員的一條費用記錄，通過病員ID去做刪除肯定是不行的，必須使用病員ID與費用條目ID組成的復合主鍵來進行刪除。

解決的過程和辦法是：我們首先分析了與存儲工廠對應的源碼，確定了其接口定義：

public interface IDeleteFactory:IDbToBusinessEntityNameMapper

這個定義說明，數據表的主鍵不一定必須是整數或者字符串這些簡單類型，存儲工廠是使用泛型[6]來實現的，這就意味著我們可以使用任何類型來做主鍵，只要在創建刪除工廠的時候指定該類型即可。針對上面的具體案例，定義一個結構體來表達復合主鍵：

最后在創建刪除命令的函數中解析出存儲過程需要的復合主鍵參數：

4 結束語

在醫院信息系統的建設和開發過程中，尤其是目前在這種“前有古人，后有來者”的尷尬局面下進行重大的技術創新，必須在保證原有系統正常運行的情況下才可以進行，而且事先需要對新技術本身進行全面深入的研究，并在實踐中不斷完善。實踐是檢驗真理的唯一標準，要在技術創新與技術風險之間進行合理的平衡，否則就有可能鬧出邯鄲學步的笑話。但是，一旦技術創新得以成功，就好像在我們面前開啟了一扇新的窗戶，使我們從巨大的壓力下走出來，減少了枯燥繁瑣容易出錯的編碼，節省了大量的時間，為將來應用的融合和擴展鋪平了道路，達到事半功倍的效果[7]。

[1] 王革,郭剛,邱松,等.淺談遠程協同區域醫療信息化[J].中國醫療設備,2011,26(10):59-64．

[2] (美)Erich Gamma,等.設計模式:可復用面向對象軟件的基礎[M]. 李英軍,等.譯.北京:機械工業出版社,2005．

[3] Hartmut Wilms.Microsoft Patterns & Practices Team publishes RepositoryFactory[EB/OL].2007-8-23)[2011-10-31].http://www.infoq.com/news/2007/08/repository-factory,2007．

[4] 李輝軍.微軟輕量級“代碼生成器”—Repository Factory使用[EB/OL].(2007-11-29)[2011-11-13].http://terrylee.blog.51cto.com/342737/67725/,2007．

[5] Len Fenster.Effective Use of Microsoft Enterprise Library[M] .Seattle：Addison Wesley Professional,2006．

[6] 內格爾,埃夫琴,等.C#高級編程[M].7版.李銘,譯.北京:清華大學出版社,2010．

[7] (美)杜瓦爾,等.持續集成:軟件質量改進和風險降低之道[M].王海鵬,等,譯.北京:機械工業出版社,2008.

Problems and Solutions of Using Repository Factory while Building HIS Entitled for Regional Collaboration Healthcare

YU Dong
Computer Center, Bayannur First Hospital, Bayannur Inner Mongolia 015000, China

With the propelling of the new medical reform policy, regional collaboration healthcare become more important than ever. On the other side, HIS was originally designed as isolated realm. This paper demonstrates how to use Repository Factory to generate a Data Access Layer around HIS as a tie connecting each other, focuses on most specialized scenarios and shares experience with counterparts on how to solve these problems.

repository factory; regional collaboration healthcare; HIS; data access layer

TP319；TP393

A

10.3969/j.issn.1674-1633.2012.05.012

1674-1633(2012)05-0041-03

2011-11-13

2012-03-16

作者郵箱：249791562@qq.com