2007 年 02 月 的封存

CodeGear 宣佈PHP RAD開發工具 : Delphi For PHP

在過新年期間CodeGear正式宣佈了PHP RAD開發工具 : Delphi For PHP。這對於使用PHP的朋友來說應該是一個非常好的訊息,因為這代表PHP界將會出現一個新的競爭者,而且是PHP界目前尚缺乏的開發工具,那就是融合了PHP語言,編輯器,連結器,除錯器以及RAD功能於一身的現代化開發工具。Delphi For PHP的出現有著許多重要的意義,

n          對於CodeGear來說這等於是向所有開發人員證明CodeGear是一家真正重視開發人員和開發工具的公司,Delphi For PHP只是CodeGear推出的第一個全新的開發工具,CodeGear在未來也會推出其他極受歡迎的程式語言的開發工具。此外CodeGear也將開始全力擦亮原本的招牌開發工具:DelphiC++BuilderJBuilder

n          這代表CodeGear將不再錯失Web開發技術/工具,CodeGear對於Web 2.0將會持續的推出最有競爭力的技術和工具。

n          CodeGear將正式開始進入動態程式語言和開源技術的領域。

不過我相信許多人在看到Delphi For PHP這個名稱時可能會有許多錯誤的第1印象,例如:

1.         這只是一個只讓Delphi開發人員使用的PHP開發工具

2.         這個工具只能編譯Windows平台上的PHP應用程式

3.         這個工具不是符合開源碼的工具

4.         這個工具必須和Delphi一起使用

5.        

我想如果您會有這些印象的話,那麼應該是這個名稱的誤導。讓我在這裡解釋一下Delphi For PHP這個產品。

 

CodeGear之所以推出Delphi For PHP當然是有許多的原因,最主要的原因當然就是CodeGear是一家以開發工具產品為主的公司,因此當然需要推出市場上最多人使用的程式語言開發工具,或是最有技術前景,最受歡迎的程式語言開發工具。而PHP是目前在Web上僅次於HTML的技術,因此推出最好的PHP開發工具自然成為CodeGear最合理的選擇,也是CodeGear在開發工具產品最具發展的方向之一。

OK,瞭解了Delphi For PHP的發展背景之後現在我就可以解釋一下Delphi For PHP這個產品的技術細節了。

首先我要說明的是Delphi For PHP(從這之後簡稱Delphi4PHP)是一個純粹的PHP開發開發工具,開發人員在Delphi4PHP中使用正式的PHP程式語言來開發Web應用程式。Delphi4PHP支援PHP 5.x,使用Delphi4PHP開發完成的PHP應用程式可以分發到任何支援PHP的平台,例如LAMP平台,Delphi4PHP內建支援MySQL 5.x以及InterBase 2007。當然Delphi4PHP也可以支援其他流行的關連資料庫。

我想Delphi4PHP之所以命名為『Delphi For PHP有兩個最重要的原因,它們是:

1.         Delphi4PHP使用標準的PHP程式語言建立了一個類似VCL的框架: VCL For PHPVCL For PHP允許Delphi4PHP開發人員使用PHP元件的方式開發Web應用程式。由於這些PHP元件的架構非常類似VCL的元件,因此熟悉Delphi的開發人員可以輕易的上手。但是VCL For PHP擁有一個VCL無法企及的優勢,那就是VCL For PHP可以分發到任何支援PHP的平台,因為它是使用純粹的PHP程式語言撰寫的。

Delphi4PHP的分發精靈可協助開發人員佈署PHP應用程式

1.         Delphi4PHPIDE本身是使用Delphi 7撰寫的原生Window應用程式,因此它執行的速度非常的快速,體積又小。我想這一點會受到許多PHP開發人員的歡迎,因為目前許多的PHP IDE執行速度都不快。

除了上述2點之外,另外一個原因則是Delphi4PHP使用了Delphi For PHP Extension,因此Delphi4PHP允許開發人員使用原生Delphi程式語言來擴充PHP的功能,或是增加PHP應用程式的執行速度而無需使用C/C++

Delphi4PHP一個極大的競爭優勢是除了VCL For PHP之外,Delphi4PHP也可以整合其他最受歡迎的PHP框架或是函式庫。此外CodeGear也將公開VCL For PHP框架的原始程式並且把VCL For PHP也公開成開源程式碼項目,讓所有有興趣的PHP開發人員可以檢視,修改,強化和擴充。

在筆者這一段使用Delphi4PHP的時間中,第一個感覺就是快速,在習慣於使用.NETEclipse的整合發展環境之後,回到使用由Delphi 7撰寫的整合發展環境時仿佛回到了從前美好的時光,不論是打PHP程式碼或是進行開發的工作都覺得快上了許多。例如下圖是我在Delphi4PHPIDE中以視覺化的方式設計PHP Web應用程式:

 

注意右方由PHP程式碼撰寫的VCL For PHP元件,接著我可以直接在Delphi4PHPIDE中執行這個PHP Web應用程式,Delphi4PHP便會啟動它內建的Apache伺服器來執行這個PHP Web應用程式如下:

上圖中的DataGrid是連結MySQL 5.x中取得的資料,使用Delphi4PHP我只需要讓這個DataGrid元件連結Data Source元件,再連結到DataSet元件就可以自動顯示資料庫中的資料了,太方便了。而這些VCL For PHP元件都是使用純粹的PHP程式語言撰寫的,例如下圖是在IDE中開啟其中部份PHP元件的原始碼,您可以看到這些都是PHP程式語言:

當然我也可以在Delphi4PHP中撰寫中文的程式碼:

 

Delphi4PHP應該會在2007年的Q1底左右推出,讓我們準備好CodeGear2007年推出的第一個作品吧。

廣告

100 則迴響

ECO傳奇(III)

CodeGear的目標和使命

 CodeGear成立宣佈專注於開發人員和開發工具市場,並且正式以『Developers Matter(開發人員是重要的)』做為CodeGear的宗旨之後,我可以預見從2007年開始開發工具界將開始呈現新的競爭風貌,因為CodeGear不可能只以傳統的DelphiC++BuilderJava IDE為滿足。既然現在程式語言和各種開發工具正以風起雲湧之勢而蓬勃發展,CodeGear自不可能置身事外,CodeGear想要在開發工具界重拾並且延續昔日的光榮歷史,就必須在數個最流行,最具影響力的程式語言和開發技術中最得一定的地位。

果不其然,CodeGearChief Evangelist David I.在他的Blog中列出了CodeGear對於2007年的展望,其中已經透露出了一些即將出現的倪端,我在下面只列出和程式語言,IDE和技術相關的項目以及我個人的一些評論:

重點

說明

快速應用程式開發(RAD)

CodeGear所有的產品都將提供快速應用程式開發的能力

創新

Delphi, C++ Java 程式語言注入嶄新的發展活力

Web

Web 2.0, AJAX

動態程式語言

PHP, Ruby

資料庫

InterBase, DataStore

開源程式碼

使用開源程式碼,利用開源程式碼,支援開源程式碼

團隊開發

為單一開發人員,小型開發團隊以及大型開發團隊提供全新經驗

我個人認為除了David I上面的提及CodeGear2007年發展的方向之,我想David I應該也把『樂趣』加到上面的清單中,因為使用優秀技術和工具撰寫程序應該是最令人愉快的事情。讓我們再仔細解釋一下上面的清單,讀者就會瞭解『創新』和『樂趣』從何而來。

例如現在許多開發人員都在研究,開發Web 2.0Ajax,也有許多開發人員結合Web 2.0/Ajax和動態程式語言,例如RubyPHPPython,但是如果我們能夠加上RAD的整合發展環境,那麼這不是很有趣,很每令人興奮嗎?

另外目前許多開源程式架框和開源程式語言雖然都非常的優秀,但是對於許多開發人員而言為數眾多而且龐大的開源程式架框都令人不知從何下手,因此如果CodeGear能夠解決這個困難,讓大多數的開發人員能夠快速使用開源程式碼來開發應用程式,又能夠讓有經驗的開發人員不斷的強化,創新開源程式碼,那不是非常有意義嗎? 想想RAD RubyRAD PHPRAD AjaxRAD 資料庫開發是有大的想像空間?

因此我想『樂趣』,不,應該說是『開發樂趣』才是CodeGear最需要重視的發展方向,因為平凡的技術和工具在現在的時代已經無法再吸引開發社群的眼光,唯有結合傳統IDE的開發能力,現今開源程式碼的價值,10倍速時代要求的生產力,以及最重要的開發人員百花齊放的思考力才能夠形成『開發樂趣』。因此『開發樂趣』實際就代表了『創新』,『生產力』和『想像力』。

最後在現代的開發環境中沒有人是單一開發人員了,這也是許多人說的開發孤島都在消失之中。為什麼? 因為我相信現在即使有開發人員是一個人負責開發特定的軟體功能,現在也都經常上Google等搜尋網站搜尋資訊,因此培養搜尋資訊能力現在也成了開發人員必備的能力之一。但是讓我們想想為什麼開發人員要經常上Google搜尋資訊?這當然是因為我們在開發軟體的流程中會遭遇許多的困難,而Google等搜尋網站可以讓我們找到世界上已經有人解決我們面對的問題的答案。

這看起來很好,但是讓我們想想我們自己的經驗,開發人員從資料導向的程序開發進入了物件導向,我們知道這是一個比較好的開發方式。而目前使用Google等得到的結果就類似資料導向,我們在搜尋到類似的結果之後需要再消化,再整理,甚至是到修改成適合我們使用的技術,程式語言,架框等。而如果我們也能夠試著把這個搜尋過程從資料導向轉換為物件導向,那麼不是更棒嗎?這是什麼意思呢?想想,如果我們能夠從在網站上搜尋資料的方式轉換為在IDE中從全世界的開發人員中直接搜尋知道答案並且使用和我們一樣的開發人員,然後直接在IDE中進行團隊虛擬開發,那麼不就等於我們在IDE的虛擬開發社群中找到一個可以立刻服務我們的『虛擬開發人員物件樣例』嗎?

拜由虛擬同儕程序技術(Virtual Peer Programming),敏捷開發概念,團隊開發技術以及IDE本身的擴充,讓這個『虛擬開發社群』正逐漸成為可能,這也是上面清單中David I在『團隊開發』項目中暗示的意義之一吧。因此我的朋友們,讓我們以後不要再說『Google 我』,下次讓我們在IDE中說『VP我』吧,我也在等待CodeGear2007年開始在這方面的突破和進展。

在筆者撰寫本文時也和ECO R&D團隊連絡並且告知他們CSDN雜誌將刊登此篇ECO文章,因此ECO R&D經理Jesper Hogstrom先生特別寫了一封信問候大中華區的開發人員,筆者也翻譯Jesper Hogstrom先生撰寫的信件原文如下:

親愛的大中華區開發朋友們好:

歡迎來到模型驅動開發應用程式的世界。您可能已經瞭解,觀察到在開發應用程式時經常有許多不斷重覆的工作,其中有許多非常微小的事情並不會為您的應用程式增加太多的數值,但是它們仍然您撰寫,為它們除錯並且還需要不斷的維護它們。您也可能看到您的客戶有特別的企業需求但是他們對於您如何讓應用程式完成的他們的需求則不太在意,只要您能夠快速完成應用程式並且交付高品質的程式碼。

ECO能夠幫助您正確的集中焦點在您的應用程式中對於客戶端使用者有用的部份。ECO允許您使用短於以前數倍的時間產生高度複雜的應用程式,並且允許您的程式碼處理您客戶的企業問題。您專業解決問題的經驗可以完全集中在您的應用程式交付的功能,而不是花費在解決一般應用程式可能產生的問題。

撰寫ECO應用程式可以讓開發軟體進入一個新的抽象層次。ECO的核心就是使用物件導向技術設計的。您可以花費更多的思考時間在設計架構上。使用ECO,您可以快樂的享受開發的過程而不是想盡辦法避免開發中困難的部份。

我希望您會像我們一樣覺得ECO是非常令人興奮的科技,並且在使用ECO開發應用程式時擁有許多的樂趣,就像我們開發ECO技術時也是充滿了樂趣。

Jesper Hogstrom

ECO R&D研發經理

 

13 則迴響

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);

之所以會這麼簡單就是因為模型中已經定義了CategoryForum這兩個類別之間有一對多的關係,而且這兩邊的關係使用了ownedByowns來定義,因此在程式碼中我們就可以直接使用定義的關係,ECO執行時期由於是執行定義的模型,因此能夠瞭解這些程式碼的意義。如此一來開發人員只需要遵照模型的定義就可以專心的撰寫程式碼,ECO把類別之間不管是一對一,一對多,多對多的關係都自動產生了相關的程式碼,開發人員不再需要分心自行建立或是使用額外的資料結構,例如ArrayList或是Collection等。

那麼如何把上面程式碼的異動更新回資料庫中? 這非常簡單的,因為ECO提供了強大的OR Mapping技術,一旦模型定義完成之後,ECO能夠自動的根據模型而執行MDD中的模型轉換(Model Transformation)規範而把模型轉換為資料庫綱要。開發人員可以選擇要使用的資料庫是什麼,要使用的資料存取技術是什麼,ECO便會自動根據開發人員的設定完成。這個流程就避免前面本文所敘述的開發人員需要不斷的在不同的專案中撰寫重覆的資料存取程式碼。

目前ECO支援了市面上主流的資料庫,例如OracleMS SQL ServerInterBaseDB2MySQLSybase等。支援的資料存取技術則有ADO.NETBdp.NET。下面的圖形說明了這個概念。

因此藉由ECO提供的OR Mapping功能,每一個ECO類別物件就是一個可永續儲存的物件,因此我們就可以使用下面更為簡單的程式碼完成儲存上面程式碼異動的工作:

[C#]

EcoSpace.UpdateDatabase();

[Delphi.NET]

EcoSpace.UpdateDatabase;

一旦呼叫了EcoSpaceUpdateDatabse方法,ECO在執行時期就可以自動偵測已經被異動過的物件,然後藉由ECO的永續儲存服務介面執行OR Mapping的工作把異動的物件儲存在資料庫中。如此一來開發人員再也不需要花費時間重覆的撰寫資料存取程式碼來存取各種不同的資料庫,這又避免了前述的開發問題之一。

那麼ECO的物件樣例如何和.NET的圖形使用者介面元件在一起使用呢?這個意思是說ECO可以把企業邏輯物件當成是一般的.NET物件(DataSet)進而顯示在.NET元件中嗎? 當然可以,ECO使用了Adapter技術,讓ECO企業邏輯物件可以藉由ECO提供的Handler元件和.NET的圖形使用者介面元件繫結在一起。例如在下圖中筆者使用了ECOHandler元件(ehForumSite)藉由OR Mapping從資料庫中擷取企業邏輯物件,再直接和.NET內定的ASP.NET Web元件繫結在一起,如此一來這些被選擇的企業邏輯物件在ECO ASP.NET應用程式執行時就會自動顯示在瀏覽器中,就好像是開發人員自己撰寫ADO.NET程式碼從資料庫中選擇資料,建立DataSet物件,再顯示於Web元件中一樣,但是使用ECO,開發人員可以完全省略重覆撰寫這些相同程式碼的時間。

 

當然ECO除了可以繫結ASP.NETWeb元件之外,也可以使用於Winform的應用程式中,相同的企業邏輯模型可以重覆使用在ASP.NETWinformWeb ServiceWinCE的應用程式中,大幅節省重覆開發的成本。例如下圖就是使用前面相同的模型於另外一個Winform專案中執行的畫面:

也許現在讀者會有一個疑問,那就是前面敘述的ECOHandler元件(ehForumSite)如何從資料庫中擷取應用程式需要的物件呢? 是使用SQL? 可是SQL執行的結果應該是資料集(Data Set)啊,怎麼會是物件呢?

如果讀者有這個疑問的話,那非常好,這代表讀者詢問到了ECO的一個核心問題,那就是如何從資料庫中選擇ECO應用程式需要的物件? 答案就是ECO使用MDD的標準規範OCL(Object Constraint Language)語言來執行選擇物件的工作。OCLOMG定義的標準,也是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相關的影片和資料:

http://dn.codegear.com/bdntv

http://dn.codegear.com

 

ECO未來的技術發展

有趣的是,隨著OR Mapping技術在Java.NET平台的成熟並且逐漸為開發人員接受和使用之後,開發人員可以專心在開發企業邏輯物件而不再需要分神於各種不同的資料存取API和架框,開發人員也不需要小心的區別一般類別和需要永續儲存的類別。這個意思是指資料存取類別現在已經驅進為程式語言的First Class類別,開發人員只需要遵照程式語言的標準即可以透明的處理和資料來源相關的工作,這實是進代程式語言和資訊技術的一大進步,

更有趣的是現在UML建模能力幾乎已經成為主流IDE的內建功能,那麼當開發人員開始習於使用IDEUML建模功能以便使用更高階,抽象的方式來開發應用系統,再結合普及的OR Mapping技術,那麼這種工作情形的運算式等於:

IDE + UML建模 + OR Mapping

        再想想現在大多數的OR Mapping都定義了特定的語言來查詢和處理實體(Entity),例如HibernateHQLJPA/EJB 3JPQL,那麼上面的運算式可以再改為:

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技術能夠同時執行在.NETVCL平台,並且準備為未來的Win64/WinCE平台做準備

n           更新,更開放的Adapter架構,讓ECO架框能夠使用更多的資料存取技術來實作OR Mapping能力。除了現在的ADO.NET 1.xBdp.NET之外,未來可支援新一代的資料存取架框,例如ADO.NET以及CodeGear明年即將公開,極具創意的新一代架構,甚至是MS未來的OR Mapping技術以及NHibernate

n           更緊密的結合Web功能,讓ECO IV可以使用於ASP.NET 2.0Ajax應用,Web 2.0等。

n           更快的執行效率,更具延展性的資料庫對映功能

n           IDE中更多的RAD MDA/DDA功能

ECO IV將在CodeGear 2007年的產品中現身,其豐富的新功能自然是許多現在已經使用ECO的開發人員期待的新版本。

 

 

2 則迴響

ECO傳奇(I)

前一陣子為CSDN寫了一篇有關ECO的文章,CSDN為它取名為"ECO傳奇". 由於CSDN雜誌是在大陸發行而且是簡體版,因此為了讓台灣的朋友也有機會能夠看看這篇文章我在下面貼出了繁體版:
 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
 

最近這幾年來軟體工程和程式語言一樣都呈現百家爭鳴的現象,從UML/RUP,敏捷開發(AD),測試驅動開發(TDD),到功能驅動開發(FDD)以及目前快速興起,也是本文討論重點的模型驅動開發(MDD),讓整個開發社群熱鬧不已。正如不同的開發人員會根據應用程式的需求以及個人的喜好選擇使用不同的程式語言,而且同時使用數種程式語言開發應用程式已經成為常態現象,愈來愈多的開發團隊也開始導入不同的軟體工程,甚至會在不同的專案中使用不同的軟體工程。這種種的現象都代表多樣化(精緻化),品質和生產力決定了使用的程式語言和軟體工程,而不再是像以前一是由特定的資訊技術主導。

那麼什麼是模型驅動開發呢? 在稍後本文介紹ECO的發展史段落讀者就可以看到ECO之父Jan Norden先生的對於開發應用程式的觀察,相信讀者必然也會心有戚戚焉。但是在敘述ECO發展史之前,在這裡先讓筆者和各位讀者交流一下數個開發的問題。

如果讀者是擁有數年經驗的開發人員,那麼您記得到現在為止您撰寫了多少支程序嗎? 也許這個問題的答案您只能有非常模糊的感覺。沒關係,如果筆者再繼續問讀者在您撰寫的程序中您寫過多少次使用相同的資料存取技術,例如JDBCADOADO.NETBDEdbExpress等,從相同資料庫中取得資料的程式碼? 又有多少次您是把取得的資料顯示在類似的圖形使用者介面中? 您是不是有過一種經驗,那就是您的腦袋中已經知道如何完成應用程式的功能,但是您仍然需要一步一步的撰寫存取資料庫的程式碼,一步一步的設計圖形使用者介面,雖然您已經撰寫過無數類似的應用程式?

像筆者本身就擁有許多上述開發的經驗,那麼想想為什麼會有這種不斷重覆的開發工作發生? 很簡單,是因為我們平日的開發工作說穿了就是把客戶的需要不斷的對映到我們使用的技術中,我們利用各種技術記錄,分析和設計客戶的需求,再使用人工的方式對映到資料庫,對映到圖形使用者介面,對映到整合工作,對映到一堆不斷重覆工作上。也正是因為這些需要重覆進行的開發工作太多,因此許多開發人員就開始簡化客戶需求設計的時程,因為許多開發人員相信許多的細節部份可以在撰寫程式碼階段完成,而無需花費時間在『無用』的設計階段,畢竟『計劃(設計)趕不上變化』,不是嗎?

但是設計雖然不能窮盡所有開發細節,但卻能夠掌握大部份的企業邏輯,而就是這關鍵大部份的企業邏輯佔據了上述重覆的開發工作的主要部份,藉由工具我們可以自動的對映企業邏輯完成上述重覆的開發工作,而讓開發人員專注在設計更好的客戶需求模型,避免不斷的重覆相同或是類似的開發工作。

現在我們就可以簡單的說明一下什麼是模型驅動開發了。MDD的基本構想是開發人員應該專注於設計良好的企業邏輯模型,並且把企業邏輯撰寫在模型中。一旦模型設計完成之後,MDD即可提供工具自動的把企業邏輯模型對映到開發人員使用的技術。例如開發人員可以選擇使用特定的平台,資料庫,程式語言或是元件架構,如此一來就避免了開發人員需要不斷重覆相同的開發工作,也可以大幅縮減開發時程,當然MDD也支援了一個關鍵技術,那就是由此任何的設計不可能一次就完成,因此MDD也支援迭代式的開發,一旦開發人員修改了設計模型,支援MDD的工具就可以再次的進行迭代式轉換。這整個觀念如下圖所示:

Borland/CodeGear研發團隊的成員早在數年前便看到這種現象,因此也在數年前開始研發支援MDD的技術。幾年前許多人都認為MDD不切實際,這主要是因為MDD牽涉到許多先進的規範和技術,在那個時候是難以實現的。但是在這幾年來MDD的支援技術不斷的被突破,在OMG也正式規範了MDD的標準之後,MDD的產品開始出現於市場上,也讓許多開發社群瞭解到MDD帶來的生產力和開發品質。在目前市場上的MDD產品中實作最齊全,最符合MDD規範,最有生產力的產品就是Borland/CodeGearECO(Enterprise Core Objects)了。ECO和它的前身Bold已經在全世界被許多開發人員使用並且開發出了眾多的應用系統,它的生產力也獲得了證實。尤其在軟體工程盛行而且MDD被愈來愈多的人接受之後,ECO也被愈來愈多的開發人員所認識,瞭解和使用,當然,本文的目的也是為各位讀者介紹MDDECO技術。

但是為什麼ECO研發團隊會早在7,8年前就能夠預見模型驅動開發的重要性而從Win32下的Bold架框開始發展? ECO研發團隊有那些厲害的傢伙? Bold/ECO的發展過程中又發生過什麼樣的故事? 這些都要從Bold/ECO之父Jan Norden先生開始說起。

ECO的發展史

早在數年前Jan Norden先生就發覺了大多數的應用程式都有極為類似的程式碼,這些程式碼大都不斷重覆出現在應用程式的各部份,例如在圖形使用者介面呈現物件樣例中的資料以及儲存物件樣例到資料來源中。此外在維護資料的完整性方面的技術問題也不斷的出現在應用程式的開發流程中。然而在這些程式碼中最重要的應該是執行應用程式應該完成的工作,至少應用程式應該交付客戶付錢購買的功能。

Jan Norden先生開始瞭解到如果能夠藉由提供一個充滿了模型資訊的架框,那麼就有可能從其中擷取出系統主要組成部份的程式碼,進而允許開發人員集中焦點在撰寫可以真正交付客戶價值的程式碼部份。有了這個信念之後,Jan Norden先生便開始開發數個不同的架框來試著解決軟體開發過程中各種不同的基本問題。而當UML標準公佈於世而且Delphi也出現在開發工具界之後(大約在1990年的中期左右)Jan Norden先生也發現到此時是把他所有在過去幾年撰寫的架框結合UMLDelphi並且形成一個單一產品的好時機了,不久之後Jan Norden先生終於發展出了這樣的產品,那就是後來聞名的Bold

Jan Norden先生決定結合他的架框,UMLDelphi開發出新的產品後,Jan Norden先生很快的就開始在瑞典首都斯德哥爾摩(Stockholm)建立他的核心研發團隊,不久之後Bold的核心研發團隊終於形成了,這些成員包含了Jan NordenJesper HogstromJonas Hogstrom以及Anders Ivner,筆者在撰寫『Delphi MDA/DDA程序設計使用ECO』一書的過程中即經常和Anders Ivner討論ECO技術細節上的問題。

雖然後來Bold研發團隊陸續加入其他的成員,但是JanJesperJonasAnders直到現在仍然是Bold/ECO研發團隊不可或缺的主要技術人員,而且直到現在這四個人仍然為當初促使他們合在一起的信念保持著高度的熱忱和興奮之心。

 

  • ECO研發團隊的所在地:斯德哥爾摩。

大約在4年前Borland決定購買Bold技術並且把Bold研發團隊帶入了Delphi的研發團隊,這讓Bold研發團隊有了一個全新的開始。而在Bold研發團隊加入Delphi研發團隊不久之後Borland就決定讓Bold技術從Win32平台開始轉入.NET平台和C#程式語言。為了這個轉變,Bold研發團隊因此花費了大量的時間思考他們目前所擁有的東西(也就是Bold架框),什麼需要和值得保留,Bold研發團隊又需要把Bold帶領到什麼方向而且開發人員未來應該如何的使用這個新的技術。在謹慎的思考之後,Bold研發團隊終於對於未來的方向以及他們想研發的新一代產品有了基本的輪廓,這就是ECO架框萌芽的起點。

話說Bold雖然是一個強大的架框,但是Bold擁有非常龐大的API,因此對於初學者而言是非常沈重的負擔。此外Bold架框中也擁有一些難以使用的部份。因此Bold/ECO研發團隊決定大幅縮減API,讓ECO架框能夠和.NET內建的UI元件搭配在一起,並且重新整理高階的服務在一組易於使用的介面中,如此一來不但可以讓初學者非常方便上手,也符合目前物件導向架框都改為使用介面導向(Interface Oriented)的設計架構。

Borland購買了Bold技術之後的4年,Bold/ECO研發團隊為ECO架框研發出了一個更為彈性的物件導向對映器,這可以讓ECO架框非常簡單的就能夠使用各種不同的資料存取技術來存取資料來源,例如ECO架框可以藉由物件導向對映器搭配ADO.NETBdp.NETdbExpress.NET等。此外他們也研發出了OCL的分支語言Eco Action Language以便能夠處理物件的狀態和物件的生命週期研發出從資料庫綱要逆向工程以產生類別模型以及模型驅動的狀態機等先進的技術。

ECO研發團隊在研發ECO技術時,他們需要一種瀏覽語言能夠讓開發人員使用來表達如何存取模型中的元素,例如開發人員可以使用下面的語法來取得客戶發票中所有購買項目的總金額:

myInvoice.items.value->sum

        一開始ECO研發團隊自己研發了一種元素瀏覽語言,但是當他們發現OCL被公佈了之後,他們就立刻瞭解到OCL完全符合他們的需求,因此ECO研發團隊立刻開始實作OCL並且讓ECO成為世界第一個商業實作的OCL,此外AndersJonas也參與了OCL 2.0規範的定義。

 

ECO IC#Builder 1.0時出現於業界,ECO II出現於BDS 2005中,很快的ECO架框和技術就成為了BDS最耀眼,最獨特的技術,也是BDS最大的競爭力之一。到了BDS 2006ECO IIIECO已經成為了一個非常成熟的架框和技術,使用ECO開發應用程式的開發人員也愈來愈多。目前ECO研發團隊正在全力的催生ECO IV

  • ECO初始開創團隊,Jan NordenJesper HogstromJonas Hogstrom以及Anders Ivner

模型驅動開發領導者-ECO架框

ECO是根據模型驅動架構(Model Driven Architecture MDA)以及設計驅動架構(Design Driven Architecture DDA)為核心發展出來的技術,並且結合OR Mapping,圖形使用者介面繫結,物件服務以及許多其他豐富的功能而形成了以模型驅動開發(Model Driven Development MDD)為基礎的軟體工程。此外ECO也結合了RAD能力,因此在MDD實作的產品中是偏向RAD MDD,這個意思是說ECO為了快速使用MDD的開發速度,因此加入了RAD開發能力,讓開發人員能夠在IDE中像使用元件開發的方式使用ECO

ECO的開發方式是讓開發人員設計完善的使用者需求企業邏輯模型,然後 ECO執行時期環境就可以忠實的執行這個設計的模型,所有模型中定義的規範都可以自動被ECO執行時期環境自動的遵守和執行。因此我們可以簡單的說ECO能夠達到『模型即程序,程序即模型』的地步。也許讓我們舉一個範例會讓讀者比較容易瞭解ECO的開發方式。

使用ECO開發的第一步是建立使用者需求的企業邏輯模型,開發人員應該在這個模型中儘可能的設計完整的資訊,因為一旦企業邏輯模型設計完畢,ECO應用程式在執行時期就會忠實的自動執行這個企業邏輯模型,因此任何開發人員花時間在模型中設計的結果都可以自動被執行,完全避免了許多開發人員認為設計是浪費時間的工作。例如下面的企業邏輯模型簡單的模擬了一個小型論壇的ECO設計模型:

 

詳細看看這個模型,它不但定義了類別,方法和特性,更重要的是它詳細的定義了一個實際的論壇系統中類別之間的關係,因此ECO執行時期就可以自動執行這些設計的關係,例如如果我們想要在一個論壇種類(程序設計)中加入兩個論壇,那麼就可以簡單的使用下面的程式碼:

31 則迴響

自己看吧, 我不能做任何的評論!

 
奉命不能說什麼,也不能做任何的評論.真希望我也有Vista可以試試,可惜我只有XP.

2 則迴響

BDS 2006 Hotfix Rollup 2

也許您沒有注意到(我也是很偶然的發現),CodeGear最近釋出了BDS 2006的第二個Hotfix Rollup,如果您還沒有下載的話,您可以在CodeGear的網站找到這個新的Hotfix : http://www.codegear.com/Downloads/RegisteredUsers/Delphi/tabid/150/Default.aspx.

4 則迴響