ECO傳奇（II）
詳細看看這個模型，它不但定義了類、方法和特性，更重要的是它詳細地定義了一個實際的論壇系統中類之間的關係，因此，ECO執行時期就可以自動執行這些設計的關係，例如如果我們想要在一個論壇種類（程序設計）中加入兩個論壇，那麼就可以簡單地使用下面的程序代碼：
[C#]
Category aCategory = new Category(EcoSpace);
ACategory.Name = “程序設計”;
Forum aForum = new Forum(EcoSpace);
aForum.Name = “ASP.NET程序設計”;
aCategory.owns.add(aForum);
Forum aForum = new Forum(EcoSpace);
aForum.Name = “PHP程序設計”;
aCategory.owns.add(aForum);
[Delphi.NET]
aCategory := Category.Create(EcoSpace);
ACategory.Name := ‘程序設計’;
aForum := Forum.Create(Ecospace);
aForum.Name := ‘ASP.NET程序設計’;
aCategory.owns.add(aForum);
Forum aForum := Forum.Crrate(EcoSpace);
aForum.Name = ‘PHP程序設計’;
aCategory.owns.add(aForum);
之所以會這麼簡單是因爲模型中已經定義了Category和Forum這兩個類之間有一對多的關係，而且這兩邊的關係使用了ownedBy和owns來定義，因此，在程序代碼中我們就可以直接使用定義的關係，ECO執行時期由於是執行定義的模型，因此能夠了解這些程序代碼的意義。這樣一來，開發人員只需要遵照模型的定義就可以專心地撰寫程序代碼，ECO把類之間不管是一對一，一對多，多對多的關係都自動產生了相關的程序代碼，開發人員不再需要分心自行建立或是使用額外的數據結構，例如ArrayList或是Collection等。
那麼如何把上面程序代碼的異動更新回數據庫中? 這是非常簡單的，因爲ECO提供了強大的OR Mapping技術，一旦模型定義完成之後，ECO能夠自動地根據模型而執行MDD中的模型轉換（Model Transformation）規範而把模型轉換爲數據庫模式。開發人員可以選擇要使用的數據庫是什麼，要使用的數據存取技術是什麼，ECO便會自動根據開發人員的設定完成。這個流程就避免前面本文所敘述的開發人員需要不斷地在不同的項目中撰寫重複的數據存取程序代碼。
目前ECO支持了市面上主流的數據庫，例如Oracle，MS SQL Server，InterBase，DB2，MySQL和Sybase等。支持的數據存取技術則有ADO.NET和Bdp.NET。下面的圖形說明了這個概念。
因此，通過ECO提供的OR Mapping功能，每一個ECO類對象就是一個可永續儲存的對象，因此我們就可以使用下面更爲簡單的程序代碼完成儲存上面程序代碼異動的工作：
[C#]
EcoSpace.UpdateDatabase();
[Delphi.NET]
EcoSpace.UpdateDatabase;
一旦調用了EcoSpace的UpdateDatabse方法，ECO在執行時期就可以自動偵測已經被異動過的對象，然後通過ECO的永續儲存服務接口執行OR Mapping的工作把異動的對象儲存在數據庫中。這樣一來，開發人員再也不需要花費時間重複的撰寫數據存取程序代碼來存取各種不同的數據庫，這又避免了前述的開發問題之一。
那麼ECO的對象樣例如何和.NET的圖形用戶界面組件在一起使用呢?這個意思是說ECO可以把業務邏輯對象當成是一般的.NET對象（DataSet）進而顯示在.NET組件中嗎? 當然可以，ECO使用了Adapter技術，讓ECO業務邏輯對象可以通過ECO提供的Handler組件和.NET的圖形用戶界面組件綁定在一起。例如在下圖中筆者使用了ECO的Handler組件（ehForumSite）通過OR Mapping從數據庫中抽取業務邏輯對象，再直接和.NET內定的ASP.NET Web組件綁定在一起，這樣一來，這些被選擇的業務邏輯對象在ECO ASP.NET應用程序執行時就會自動顯示在瀏覽器中，就好像是開發人員自己撰寫ADO.NET程序代碼從數據庫中選擇數據，建立DataSet對象，再顯示於Web組件中一樣，但是使用ECO，開發人員可以完全省略重複撰寫這些相同程序代碼的時間。
當然ECO除了可以綁定ASP.NET的Web組件之外，也可以使用於Winform的應用程序中，相同的業務邏輯模型可以重複使用在ASP.NET，Winform，Web Service和WinCE的應用程序中，大幅節省重複開發的成本。例如下圖就是使用前面相同的模型於另外一個Winform項目中執行的畫面:
也許現在讀者會有一個疑問，那就是前面敘述的ECO的Handler組件（ehForumSite）如何從數據庫中抽取應用程序需要的對象呢? 是使用SQL嗎? 可是SQL執行的結果應該是數據集（Data Set），怎麼會是對象呢?
如果讀者有這個疑問的話，那非常好，這代表讀者詢問到了ECO的一個核心問題，那就是如何從數據庫中選擇ECO應用程序需要的對象? 答案就是ECO使用MDD的標準規範OCL（Object Constraint Language）語言來執行選擇對象的工作。OCL是OMG定義的標準，也是MDD的子規範之一，OCL可以使用在模型中定義業務邏輯，因爲OCL定義了許多的操作數，OCL也可以使用於選擇對象，提供類似於SQL的能力。只是SQL選擇的結果是數據集，而OCL執行的結果則是對象或是對象集。
例如前面的ehForumSite組件即使用了下面的OCL從數據庫中選擇出所有的論壇網站對象：
ForumSite.allInstances
當然，OCL也定義了豐富的選擇操作數讓開發人員使用更精確的條件來抽取對象，例如我們可以使用下面的OCL選擇出所有論壇種類中包含多於一個論壇主題的論壇種類對象:
Category.allInstances->select(c| c.owns.size() <> 0)
OCL也允許使用巢狀或是串聯的語法，例如下面的OCL可以抽取出所有有QA問題但是尚未回答的研討會對象：
DevCoSeminar.allInstances.select(s | (s.hasQA.size() > 0) and (s.hasQA.select(not closed)->size() > 0) )
由此上面簡單的敘述可知，OCL可以同時使用在靜態的模型中定義業務邏輯，也可以於執行時期動態的使用ECO組件來執行，例如下圖就是在ECO應用程序執行時期動態執行OCL並且取得結果對象集:
OCL提供了豐富的運算方式，有興趣的讀者可以在OMG的官方網站找到OCL相關的規範和文件。
爲了滿足開發人員對於複雜應用程序的開發需求，ECO還提供了豐富的服務框架，例如提供交易管理的服務，執行對象Undo/Redo的服務，快儲服務，對象池服務，訂閱服等高級應用框架服務，讓開發人員能夠使用來撰寫應用程序。這些服務都是以現代框架架構設計，實作的，也使用了接口導向，讓開發人員只需要取得需要服務的界面即可使用ECO服務框架提供的服務而無需開發人員自己花費時間撰寫這些應用程序都共通需要使用的功能。
最後我們可以把整個ECO技術提供的架構敘述如下:
n 展示層（Presentation Layer）： ECO提供的各種Handles組件以便讓數據和.NET的控件結合在一起。
n 業務邏輯層（Business Layer）：開發人員在ECO類別中實作的程序代碼
n 服務層（Service Layer）：ECO框架提供的各種服務，例如處理異動對象的IDirtyListService接口，服務層也是本章討論的重點。
n 框架層（Framework Layer）：ECO內部的實作程序代碼。
下圖顯示了ECO中服務層和框架層的關係：
· ECO框架的設計架構
由於ECO提供的強大的功能以及豐富的應用程序開發能力，筆者建議有興趣的讀者可以到CodeGear的官方網站下載展示如何使用ECO開發應用程序的影片，就可以瞭解ECO強大，快速的開發能力。讀者可以在下面的URL找到ECO相關的影片和資料:
ECO未來的技術發展
有趣的是，隨着OR Mapping技術在Java和.NET平臺的成熟並且逐漸爲開發人員接受和使用之後，開發人員可以專心在開發業務邏輯對象而不再需要分神於各種不同的數據存取API和框架，開發人員也不需要小心的區別一般類別和需要永續儲存的類別。這個意思是指數據存取類別現在已經驅進爲程序語言的First Class類別，開發人員只需要遵照程序語言的標準即可以透明的處理和資料來源相關的工作，這實是進代程序語言和信息技術的一大進步，
更有趣的是現在UML建模能力幾乎已經成爲主流IDE的內建功能，那麼當開發人員開始習於使用IDE的UML建模功能以便使用更高階，抽象的方式來開發應用系統，再結合普及的OR Mapping技術，那麼這種工作情形的表達式等於:
IDE + UML建模 + OR Mapping
再想想現在大多數的OR Mapping都定義了特定的語言來查詢和處理實體（Entity），例如Hibernate的HQL，JPA/EJB 3的JPQL，那麼上面的表達式可以再改爲:
IDE + UML建模 + OR Mapping + 對象查詢語言(HQL/JPQL)
不過如果我們考慮到爲什麼在OR Mapping技術成功的消弭了一般實體和數據存取實體之間的籓籬時爲什麼要要使用這麼多種不同的實體查詢語言?而且實體查詢語言又不能使用在業務邏輯模型之中，那麼什麼是可以同時使用在高階企業模型之中定義業務邏輯，又同時能夠使用在程序語言中查詢業務邏輯對象呢? OCL不正是身兼者之長嗎?因此如果我們把OCL帶入上面的表達式時可以得到如下的結果:
IDE + UML建模 + OR Mapping + OCL
此時如果我們回去看看MDA/DDA的規範，可以發現UML建模 + OR Mapping + OCL正是關鍵的技術標準。這意謂着:
UML建模 + OR Mapping + OCL ~= MDA/DDA
而上面表達式中的功能如果提供在現代IDE之中，那麼就形成了下面的結果:
IDE + UML建模 + OR Mapping + OCL ~= RAD MDA/DDA
這也就是說MDA/DDA的條件也即將慢慢的普及於未來的IDE之中，也許大多數的開發單位不會使用MDA/DDA全部的功能來開發軟件，但是當他們日後閱讀有關MDA/DDA的數據時可能會很驚訝的發現到他們早已使用部分MDA/DDA的規範在開發軟件。
其實朝向使用MDA/DDA或是使用部分MDA/DDA開發軟件是非常自然的發展，當現代程序語言和OR Mapping等技術不斷的消除不同技術之間的歧異之後，讓對象導向技術往前更邁進了一大步，這也正朝向解決對象導向技術“最後一哩”的關鍵，那就是讓開發人員在使用對象導向技術開發軟件時，所有需要使用的技術都是First Class。而當這個目標逐漸達成時，開發人員就自然會從技術細節中脫身，轉而從模式或是架構的角度來思考軟件，這當然是因爲底層的技術都通透化了，進而允許我們達成“編碼即建模，建模即編碼”，這也正是MDA/DDA的發展的思想。
好了，在簡短的說明了軟件開發可能的發展趨勢之一後，那麼在ECO III之後CodeGear會如何持續的發展ECO技術呢? 嚴格的說，ECO III是一個非常成功的版本，因爲ECO III的功能集不但已備完善，非常穩定，而且使用的羣組，人數也非常的廣泛。因此ECO IV的戰略方向應該是朝擴大戰果發展，從CodeGear即將公佈的路線圖中可以瞭解ECO IV的發展重點如下:
n 延伸支持VCL.NET，讓ECO技術能夠同時執行在.NET和VCL平臺，並且準備爲未來的Win64/WinCE平臺做準備。
n 更新，更開放的Adapter架構，讓ECO框架能夠使用更多的數據存取技術來實作OR Mapping能力。除了現在的ADO.NET 1.x和Bdp.NET之外，未來可支持新一代的數據存取框架，例如ADO.NET以及CodeGear明年即將公開，極具創意的新一代架構，甚至是MS未來的OR Mapping技術以及NHibernate。
n 更緊密的結合Web功能，讓ECO IV可以使用於ASP.NET 2.0，Ajax應用，Web 2.0等。
n 更快的執行效率，更具延展性的數據庫對映功能。
n 在IDE中更多的RAD MDA/DDA功能。
ECO IV將在CodeGear 2007年的產品中現身，其豐富的新功能自然是許多現在已經使用ECO的開發人員期待的新版本。
|
|
|
|
|
|
||
|
|
|
|
|
|
||
|
|
|
|
|
|
|
|