2006 年 10 月 的封存

回應客戶要求:C++Builder 3/Delphi 4/Delphi 5書籍開放下載

在上次去高雄進行技術研討會時,一位與會的客戶提出了一個問題,那就是他仍然有Delphi 5的專案在進行開發之中,雖然他也想昇級到BDS 2006,但是他也需要Delphi 5的資料或是書籍,但是目前在市面上已經找不到這些舊版的書籍,他問我是不是可以把我以前舊的Delphi書籍開放出來讓他們這些仍然有需要的人可以使用。

在這位朋友提出了這個問題之後讓我的思緒仿佛立刻回到了數年前的時光,沒有想到時間過的這麼快,我和李匡正在晶華飯店發表Delphi 5的情景還歷歷在目呢。

在研討會回來之後由於工作忙碌而且我試著從成堆的CD中找尋這些舊版Delphi/C++Builder書籍的電子稿,翻遍了成堆的CD之後終於找出了2片發霉的CD,處理了之後終於回復了幾本Delphi/C++Builder書籍,在我把這些書籍整理好之後我會放在 :

  http://Liwei.csdn.net

上讓有需要的朋友下載,

另外如果各位想討論有關DevCo工具的技術問題,也可以拜訪:

  http://liwei.csdn.net/forum

在那裡我希望慢慢建立一個DevCo GC專屬的論壇,Cheers!

10 則迴響

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

這一段時間我沒有寫任何的Blog,主要的原因除了是忙於即將到來的技術研討會之外,另外的原因就是最近一口氣閱讀了『長尾理論』,『歷史家』,『吳清源傳』和『林海峰傳』4本書。這4本書都非常的精彩,讓我無法不一次讀完,因此過去的2個星期都在閱讀和思考中度過。『長尾理論』和『歷史家』這2本書不但讓我享受閱讀的樂趣,也讓我的腦袋在閱讀時不停的思考。例如閱讀『長尾理論』時我不停的思考書中的內容如何對映到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)?

這個問題和第1位作者說的『適宜已有資料庫的系統甚至是異構的資料庫系統』有關,簡單的說是許多人就是在問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!

19 則迴響

意料之外的收穫!

上星期我在台北,台中和高雄進行了Delphi/Delphi.NET多層應用系統開發技術II的研討會,討論了有關MDA/DDAECO相關的技術。這場研討會除了在台北做Demos時出了一些小問題,在台中和高雄的研討會都進行得非常的順利,而且台中和高雄的朋友反應非常的熱烈,有人甚至建議我把全場的研討會錄影下來公佈在網路上,這樣可以讓更多的人瞭解MDA/DDA/ECO開發的好處。

這次的研討會對於我個人來說都覺得非常的有收穫,這和這次展示的範例有關,讓我把原由說清楚一點。

這是因為當我開始準備這場研討會的範例時,一開始我只是想著要如何展示使用ECO開發的好處。由於已經在台灣進行過數場ECO的技術研討會,因此許多朋友已經看過許多簡單的ECO範例,因此我必須想出一些不錯的範例才能夠吸引來參加的客戶,更重要的是必須在短短的展示時間之內讓客戶瞭解到MDA/DDA/ECO的優點以及使用ECO強大的開發能力。

由於上一次的技術研討會是有關如何把Delphi Win32以及Midas的應用程式移植到.NET中,因此在這次的研討會中我的想法是展示如何開發多層的ECO應用系統。在.NET虛擬執行環境中要開發分散式應用系統就需要使用.NET Remoting,但是要使用.NET Remoting撰寫複雜的系統需要許多的程式碼,而ECO是使用模型驅動開發的架框,主要的目的是希望開發人員能夠把開發的焦點集中在企業邏輯的設計,儘量減少特定平台和技術對於企業邏輯模型衝擊。因此在使用ECO進行分散式應用系統開發時也應該儘量降低.NET Remoting為了對於開發的影響,最好的狀況是結合ECO.NET Remoting時應該是透明,簡單的。ECO III確實做到了這一點,它藉由提供PersistentMapperProviderPersistenceMapperClient兩個元件以及預先產生的程式碼,可以立刻讓開發人員實作出使用.NET RemotingECO伺服器以及ECO用戶端應用程式,完成ECO分散式應用架構。

在我成功的完成這個範例ECO分散式應用程式後,我突然瞭解,在我實作這個範例的過程中,.NET Remoting並沒有對於企業邏輯模型有任何的影響,.NET Remoting也是在企業邏輯模型完成之後才加入的特定功能,因此在理論上使用ECO架框開發應用程式應該可以開發所有型態的應用系統,我的意思是說在企業邏輯模型開發完成付後,我們可以把它使用在桌上型(Desktop)應用系統,主從架構應用系統,Web應用系統,分散式應用系統,甚至是Mobile的應用。

有了這個想法之後我立刻重新設計我的範例,讓這個範例展示如何使用ECO架框進行開發的工作。我先使用ECO III建立範例企業邏輯模型,然後展示使用它來開發桌上型應用程式,又使用它開發ASP.NET應用程式,再使用於主從架構應用程式,接著結合.NET Remoting開發成分散式應用系統,最後再把它使用在Web Service應用程式中,並且使用Delphi For Win32開發用戶端來使用ECOWeb Service應用程式。整個的範例一氣呵成,讓使用ECO架框進行開發充滿了樂趣,也充分的展示了ECO架框迷人之處。下面的圖形說明了這整個概念:

 

完成了研討會的範例準備之後,連我自己當初都沒有想到這樣的應用,感覺這次舉辦的研討會我個人都收穫豐富。希望以後DevCo舉辦的研討會不但能夠讓客戶覺得值回票價,我們DevCo自己人也能夠玩得高興,賓客盡歡。

14 則迴響