收穫豐富的兩個星期和ECO OR Mapping

收穫豐富的兩個星期和ECO OR Mapping

這段時間我沒有寫Blog,主要的原因是除了忙於即將到來的技術研討會之外,另外就是最近在閱讀《長尾理論》、《歷史家》、《吳清源傳》和《林海峯傳》四本書。這四本書都非常精彩,讓我無法不一次讀完它們,因此過去的兩個星期都是在閱讀和思考中度過的。《長尾理論》和《歷史家》這兩本書不但讓我享受閱讀的樂趣,也讓我的腦子在閱讀時不停地思考。例如閱讀《長尾理論》時我不停地思考書中的內容是如何對映到IT界的,《長尾理論》又是如何解釋Borland/DevCo最近的狀況和演變的,《長尾理論》又是如何可以對映到我的學習之路和未來的發展的。而在閱讀《歷史家》時除了享受故事內容的同時,我也從IT人的思考角度找到了書籍內容中數個不合理的臭蟲,而這一點我太太則是嘲笑我的職業病已經快到了無可救藥的地步,不過《歷史家》最後的結局卻讓我思考爲什麼卓九勒只是“歷史家”而不是“程序員”,因爲卓九勒發展出來的搜尋技術早己遠遠超過Google,如果卓九勒把它發展成“吸血鬼搜尋引擎技術”的話,那麼不但可以發大財,而且幾乎可以掌控世界,呵呵。

關於《長尾理論》的想法等我有時間了再詳細介紹給大家,這次先讓我談談有關OR Mapping的問題吧。

由於最近我在收尾ECO程序設計一書,正好寫到有關ECO OR Mapping的內容,爲了補充我個人在這方面的知識,因此我在Google上搜尋有關ECO OR Mapping相關的內容,有趣的是我看到了許多有關的討論。許多人都關心ECOOR Mapping技術,也非常有興趣,有人甚至詢問ECOOR MappingHibernate/NHibernate的比較,也有許多人擔心ECO OR Mapping的透明性,以及如何在已有/舊的數據庫模式和數據庫數據上使用逆向工程產生封裝類,但是又想在不改變已有/舊的數據庫模式的狀態下能夠加上新的數據庫數據表和封裝類?

當然,對於這些問題也有許多人回答,提供了各種不同的答案。例如下面的一段話是我在某個有關OR MappingBlog中看到的:

我沒有研究過NHibernate,不過我深入研究過ECO/ECOII,當然現在是ECOIII了。從設計目標上講,ECO是非常優秀的,模型來自於UML,透明度極高,但是對數據庫的控制度很低,這一點我不太能接受,因爲完全照UML來設計數據庫稍稍控制不好會導致一些嚴重的性能問題(我親自經歷過的案例)。我的目標僅僅是來自ER模型,設計時的透明度會有所降低,但對數據庫的控制度比較高,並且既適宜新構建的系統又適宜已有數據庫的系統甚至是異構的數據庫系統。

我看了這段話之後我不太能理解作者說的ECO對於“數據庫的控制度很低”是什麼意思? 另外這段話又說“適宜已有數據庫的系統甚至是異構的數據庫系統”,我在想ECO也提供了這些功能啊。

另外我又常常看到下面的問題:

我知道直接從ECO model產生的table會有ECO_IDECO_TYPE等字段,請問要如何做才能享受用model修改的方便但又不變動原有數據庫(可加新table?

這個問題和第一位作者說的“適宜已有數據庫的系統甚至是異構的數據庫系統”有關,簡單地說,是許多人在問ECO如何能夠和現有存在的系統共存? 讓開發人員能夠在不影響舊有系統的數據情形下能夠使用ECO技術開發後續的系統?

如果讓我整理一下上面的問題,其實都是和ECOOR Mapping有關,ECO不管是使用正向工程從業務邏輯模型自動產生數據庫模式,或是從現有的數據庫模式中以逆向工程產生封裝類,開發人員都可以控制ECOOR Mapping運作機制,其中的關鍵點就是ECO是一個RAD MDA工具,爲了讓開發人員快速使用MDA/DDA開發應用系統,因此,把OR Mapping做得非常自動化,讓許多人誤以爲ECOOR Mapping對於“數據庫的控制度很低”,或是無法在現有的系統中結合ECO,因爲ECOOR Mapping會自己產生相關的數據庫模式來運作。

其實ECOOR Mapping可以像Hibernate/NHibernate使用XML來定義OR Mapping的規則,在ECO中這稱爲自定義 OR Mapping功能。開發人員可以在正向工程產生了數據庫模式之後,結合FileMapperProvider和自定義 OR Mapping功能進行數據庫的控制工作,而且開發人員在瞭解了ECO業務邏輯模型後,ECO內置上的OR Mapping機制,OCL轉換SQL原理之後,甚至可以使用SQL來處理數據。

同樣,在逆向工程方面也是如此,ECOOR Mapping除了可以根據現有的數據庫模式產生封裝類之外,也允許開發人員自己在數據庫中建立新的數據表,再借助ECO的設計器自動產生封裝類,最後藉助自定義 OR Mapping來定義新的數據表和新的封裝類之間對映的關聯,就像Hibernate/NHibernate一樣。

爲了讓各位對於自定義 OR Mapping有概念,讓我使用一個許多人都熟悉的範例,就是使用ECO的逆向工程從數據庫產生封裝類,接着再使用自定義 OR Mapping來增加新的數據表和新的封裝類而不破壞已有的數據表和數據。這個範例使用InterBase的範例數據庫employee.gdb來說明。

首先建立一個ECO ASP.NET項目,在FileMapperProvder中放入PersistentMapperBdp和連接到employee.gdbBDP連接,接着在FileMapperProvder設計器中啓動Wrap existing Database with Eco菜單以進行逆向工程,之後就會產生waORMappingDemoOrMapping.xml這個對映文件和如下的類架構:

例如現在我們就可以執行這個ECO ASP.NET應用程序,從下圖中就可以看到ECO ASP.NET應用程序可以正確地使用面向對象的對象處理存在於employee.gdb之中的關聯式數據了:

接着讓我們關閉項目,然後自行在employee.gdb中建立一個新的數據表TestTable,如下:

由於在前面我們已經使用逆向工程建立了封裝employee.gdb的類,而現在在employee.gdb中又新增了一個TestTable數據表,那麼我們如何在不影響原來的數據情形下加入TestTable數據表到ECO的項目中?

這其實很簡單,關鍵點是兩個文件的內容,它們是定義封裝類和數據庫模式之間對映的規則的文件:waORMappingDemoOrMapping.xml。以及敘述逆向工程的整個模型:EmployeePackage.ecopkg。只要開發人員適當地處理這兩個文件的內容就能夠完成這項工作。

首先讓我們處理對映的規則的文件:waORMappingDemoOrMapping.xml。這個文件就像Hibernate/NHibernate使用的對映配置XML文件一樣,開發人員可以藉助修改其中的內容來自定義ECO是如何對映封裝類和數據表的。現在我們需要在waORMappingDemoOrMapping.xml中加入一個新的類,定義如下:

  <ClassDef Name="TestTable">

    <AliasDef Name="TestTable_1" Database="employee" Table="TESTTABLE" ExtentRequiresDiscriminator="False" IsMainAlias="True">

      <KeyImpl Name="EcoKey">

        <KeyColumn Name="TID" />

      </KeyImpl>

    </AliasDef>

    <KeyDef Name="EcoKey" Signature="System.Int32" IsId="True" KeyMapper="Attribute"/>

    <AttributeDef Name="ID" Alias="TestTable_1" Columns="TID" />

    <AttributeDef Name="FName" Alias="TestTable_1" Columns="FNAME" />

  </ClassDef>

一旦加入了這個類定義,ECOOR Mapping就知道業務邏輯模型中存在了TestTable

接着再於waORMappingDemoOrMapping.xml中加入下面敘述TestTable數據表模式的信息:

<Table Name="TESTTABLE">

  <Column Name="TID" AllowNULL="False" Type="" Length="4" DefaultValue="" />

  <Column Name="FNAME" AllowNULL="False" Type="" Length="50" DefaultValue="" />

</Table>

一旦擁有了這兩個定義,ECO就知道TestTable類是對映到TESTTABLE數據表。

現在我們需要讓ECO的業務邏輯模型知道有了新的TestTable類的存在,所以我們可以在ECO類設計器中加入TestTable類,如下:

這個目的是讓TestTable類能夠正確地敘述在整個業務邏輯模型的文件EmployeePackage.ecopkg之中。

完成了這些操作之後,再次執行範例應用程序,我們就可以看到如下圖所示的畫面:

TestTable果然正式加入了我們的業務邏輯模型,而且我們的確可以在ECO ASP.NET應用程序中處理這個數據表的數據:

當然,開發人員也可以在這個藉助逆向工程產生的ECO ASP.NET應用程序中使用SQL來處理原有的數據,它的透明度和任何傳統的數據庫應用程序是一樣的。

Delphi 2006的手冊中有更多關於自定義的ECO OR Mapping的數據,藉助這些自定義的功能,開發人員可以定義任何複雜的自定義OR Mapping的工作,Have Fun!

李維先生簡體版博客由博文視點陳元玉編輯負責繁轉簡以及版式設計,如有疑問敬請您與編輯聯繫,聯繫方式:[email protected]  

 

 

 

 

 

 

 

 

 

 

 

 

 
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章