http://spaces.msn.com/members/GordonLiWei/Blog/cns!1pd9F9rOlOiQSBatvHQlivdg!310.entry

A shift in mind!(寫於龍王颱風肆虐台灣的一天)

自從Delphi團隊決定把ECO做為主打的技術之一後，我們就可以看到許多的活動就開始圍繞著ECO，例如我剛和John Kaster在大陸做完的Delphi 2005技術之旅以及前一陣子我在台灣做的ECO技術研討會等。最近Borland的BDN也有了許多有關ECO的文章和教學影片，希望能夠讓開發人員瞭解ECO的好處。事實上早在Delphi 8的時候就已經開始宣傳ECO的觀念和技術，在2年前於大陸的Borland Developer Conference之中我們也安排了2場有關ECO的研討會，然而效果卻不如預期，為什麼?因為當時並沒有多少人瞭解MDA/DDA，因此許多來聽的人可能都覺得是鴨子打雷。而知道MDA/DDA的人也有許多並不相信MDA/DDA的技術以及MDA/DDA能夠成功。




對於Delphi的歷史來說，Delphi曾經多次引領了技術的潮流，Delphi 1以VCL元件模型徹底打敗了MS的VBX，Delphi 2是第一個純32位元的RAD開發工具並且成功的引入了主從架構的技術，Delphi 3提倡的多層分散式架構，Delphi 5讓MIDAS和多層分散式架構進入成熟應用的階段，Delphi 6扮演的Web Service先知角色等，都是熟悉Delphi的開發人員熟知的歷史。不過如果我們仔細的回想一下上述在當時算是最新，最火熱的技術，我們會發覺這些技術對於開發人員如何撰寫應用程式的『程式心智』的改變並不算大，因為都是使用Delphi提供的元件使用熟悉的RAD方式來開發，因此大多數的開發人員並沒有太多的困難就可以接受並且掌握這些技術。



但是ECO則不同，甚至和使用Delphi程式語言加上物件導向的方式都不同。使用ECO開發應用程式需要開發人員在『程式心智』上的改變，因為ECO和以往大多數Delphi開發人員使用RAD的方式，或是另外一些使用Object Pascal程式語言加上自己撰寫類別以物件導向方式來開發應用程式都不同。ECO則不同，使用ECO需要開發人員使用不同的『程式心智』，ECO會強迫開發人員把應用程式的企業邏輯轉換為模型，因為ECO是以您設計的模型來驅動執行的，您的應用程式就是您的模型設計結果。改變『程式心智』很難嗎? 很難說，但是對於大部份的開發人員來說可能是的，因為我們都太習慣於使用RAD，程式碼的開發模式。但是我以過來人的經驗和您分享，一旦您掌握了ECO的開發『程式心智』，您一定會喜歡上它，因為它其實非常符合我們的思考模式。



在我前一陣子出版的2本書『面向對象開發實踐之路(C#/Delphi)』中討論了如何使用物件導向的方式來處理文件。在這本書中我幾乎完全使用物件導向的方法來實作，和RAD的關係很少。然而在最近使用Dexter中的ECO時，我就在想如何結合ECO的模型開發能力和『面向對象開發實踐之路』之中已經寫好的眾多類別呢? MDA/DDA的開發模型可以和物件導向的模式結合嗎? 其實這一點都不難，『面向對象開發實踐之路』之中的PFM類別提供了以各種不同的方式處理處理各種不同文件的能力，但是如果需要處理的文件之間有架構的關係，或是需要分門別類時，PFM類別就沒有提供任何的支援了。這是什麼意思?假設我希望先把文件分門別類，例如Word種類，MP3種類，技術文件種類，Delphi元件種類等等。然後在每一種類的文件中再放入這種種類的所有文件，而如果文件還擁有2進位的內容，那麼我還需要連結特定的文件和它所有的2進位的內容。例如下面就是一個很好的範例:



l 產品發表
n Delphi 7產品發表
u Delphi 7產品發表Slide
u Delphi 7產品發表範例程式
u Delphi 7產品發表範例資料
u ….
n Delphi 2005產品發表
u …


在產品發表種類中會存在各種不同的特定的產品，而在特定的產品之下又有許多和它相關的2進位的內容。



現在我需要結合文件分門別類的功能，以及PFM類別能夠處理各種文件的功能，我應該如何解決?



這並不困難，因為ECO可以提供模型設計來解決文件分門別類的功能。因此我可以立刻在Dexter中建立一個ECO專案，並且設計如下的模式架構:



上圖中CMCategory代表文件的種類，例如上面的產品發表。CMMember代表CMCategory中所有的文件，例如上面的Delphi 7產品發表。而CMElement則代表特定文件的2進位的內容，例如上面的Delphi 7產品發表Slide。您可以在看到在模型中我定義了一個CMCategory擁有(owns)1到多個CMMember，而一個CMMember則擁有(has) )1到多個CMElement，其他的關係請您自己推看，非常的簡單而且符合企業邏輯。而CMCategory，CMMember和CMElement都從CMEntity繼承下來。



這個模型定義了文件之間的架構關係，再結合PFM類別就可以完全解決我需要對文件進行分門別類的處理並且以各種不同的方法處理各種不同的文件的需求了。



知道我在使用ECO時花最多的時間在什麼地方嗎? 沒錯，就是在設計模型的階段，我花了更多的時間來設計應用程式本來就應該解決的企業邏輯模型，我把要解決的問題使用ECO模型設計家設計出來，集中思考企業邏輯和設計架構，而不是直接跳到程式碼中。



那您也許會問使用ECO和直接使用物件導向的差異在那裡? 其實不多，因為使用ECO和使用物件導向都需要設計，但是ECO提供了許多使用物件導向開發模式時需要的服務，它們是:

n 執行時期的物件空間

n OR-Mapping

n 物件服務架框

n 物件查詢能力

n 和.NET GUI連結的連結



就算不使用ECO，開發人員也需要上述的服務，下面的表格列出了使用ECO和不使用的ECO差異:


不使用ECO
ECO

執行時期的物件空間
開發人員需要撰寫大量處理物件的程式碼(Caching，Dirty Object，Persistent)
EcoSpace

OR-Mapping
使用ADO.NET或是Hibernate等等
ECO的OR-Mapping技術

物件服務架框
沒有，需要自行撰寫
ECO Framwork

物件查詢能力
SQL, HAL等等
標準的OCL，Action Language

和.NET GUI連結的連結
沒有，需要自行撰寫
已經提供





看吧，ECO提供的都是不可或缺的功能和服務。



好了，回到剛才的例子，在這個結合ECO和PFM類別的範例中，如果我需要建立CMCategory和CMMember之間的關係，那麼在ECO中是如此的容易和直覺，例如在下面程式碼中，我只需要先建立CMMember物件(003)，再於005取得目前的CMCategory物件，呼叫它的owns.add就完成了。為什麼?回頭看看前面的ECO模型，在模型中清楚的定義了CMCategory owns CMMemebr，而且是1到多個CMMember，因此我們使用owns.add。現在想想如果是您自己要寫物件之間的關係的程式碼的話，您需要撰寫多少的程式碼?此外別忘記了，在ECO中我可以直接把物件之間的關係使用一行程式碼儲存到資料庫之中，如果是您自己來做的話，又需要撰寫多少行的程式碼? 其實問題不在於要多少行程式碼，而是ECO可以讓您專心使用程式碼處理企業邏輯，而不是其他太多不相關的程式碼。

001 private void btnAddMember_Click(object sender, System.EventArgs e)

002 {

003 CMMember aMember = DocuManagerFacade.DoAddMember(EcoSpace,

004 this.tbMemberName.Text, this.rtbMemberDescription.Text);

005 GetCurrentCategoryObject().owns.Add(aMember);

006 ShowDirtyObjectCount();

007 }



Voila，很快的完成了這個ECO應用程式之後，我們可以看到下面的畫面我已經開始把文件分門別類了:



最後讓我們看看我如何使用PFM類別自動備份所有屬於MP3種類的文件和它的2進位內容。我先使用DoAutoBackup()建立TPFMConfig物件，再建立TFileFinder物件，最後呼叫DoBackupAllFiles進行自動備份的工作(這些都是PFM類別物件)。



public static void DoAutoBackup(PCMStep1EcoSpace EcoSpace, CMCategory aCategory, CMMember aMember,

System.Windows.Forms.ProgressBar pb, System.Windows.Forms.RichTextBox rtb, string sDir, string sExt, bool bZip)

{

TPFMConfig aConfig = CreatePFMConfig(sDir, sExt);

TFinder aFileFinder = TFinderFactory.CreateFinder("FILEFINDER", aConfig);

DoBackupAllFiles(EcoSpace, aCategory, aMember, pb, rtb, aConfig, aFileFinder as TFileFinder, bZip);

}



DoBackupAllFiles()先根據目前的CMCategory物件找到CMMemebr或是建立CMMemebr物件，最後再根據TFileFinder找到的每一個TCandidate物件建立一個相對應的CMElement物件，再使用TPFMHandler物件處理文件內容，最後呼叫CMElement物件的setElementContent方法把2進位資料儲存到CMElement物件中。當ECO應用程式結束時，便會使用ECO的OR-Mapping技術自動的把所有的物件儲存到資料庫中，包含物件之間的關係和2進位資料。

private static void DoBackupAllFiles(PCMStep1EcoSpace EcoSpace, CMCategory aCategory, CMMember aMember,

System.Windows.Forms.ProgressBar pb, System.Windows.Forms.RichTextBox rtb, TPFMConfig aConfig, TFileFinder aFinder, bool bZip)

{

CMMember theMember = aMember;

SetupProgressStatus(pb, aFinder.GetCount());

if (theMember == null)

{

theMember = DoAddMember(EcoSpace, aCategory.Name, "");

aCategory.owns.Add(theMember);

}



foreach (TCandidate aCandidate in aFinder)

{

if (aCandidate != null)

{

TPFMHandler aHandler = CreateHandler(bZip);

byte[] bData;

try

{

CMElement aElement = DoAddElement(EcoSpace);

theMember.has.Add(aElement);

FileInfo fi = new FileInfo(aCandidate.Name);

aElement.Name = fi.Name;

aElement.Format = aConfig.Ext;

aElement.oriFileName = aCandidate.Name;

bData = aHandler.Perform(aCandidate, null);

aElement.setElementContent(bData);

UpdateProcessingInfo(pb, rtb, aCandidate);

}

finally

{

bData = null;

aHandler = null;

}

}

}

}

}



下圖就是ECO應用程式執行並且根據條件自動備份文件的執行畫面，我簡單的結合ECO和PFM類別就完成了文件架構和處理文件的需求，又好玩又有效率。




下圖更cool，我使用OCL查詢物件的能力，在TextBox中輸入Delphi，便可以在產品發表這個種類中找出所有和Delphi相關的特定文件，而在找到所有和Delphi相關的特定文件後，一旦我點選了其中的一個文件，例如下圖的Delphi 8，我就可以藉由模型中CMMember的has association而找到所有屬於Delphi 8的2進位資料了，so easy。



網友CSharpvsDelphi的http://dotnet.vcl.com.tw網站使用了.NET 2.0技術來開發，雖然我不知道他的程式碼如何寫的，但是我使用ECO也能夠很快的開發出類似的東西，因為我在玩了一下他的網站之後出現在我的腦中的東西並不是ASP.NET 2.0有了那些新的技術，而是在腦中浮現他的網站的架構和邏輯，因為我很快的使用ECO設計了網站的架構:





發覺了CSharpvsDelphi和我的不同了嗎?

p.s. CSharpvs.Delphi, 你的網站很棒, 我也註冊了.

嗯，我怎麼感覺我愈來愈像在寫書而不是在寫Blog? 寫得太認真了，已經有網友吐嘈我的Blog除了IT幾乎沒有其他的東西，太硬了。也許下次應該寫些言不及義的東西好了，=_=!。













12:37 | 固定链接 | 评论 (5) | 引用通告 (0) | 记录它


固定链接

http://spaces.msn.com/members/GordonLiWei/Blog/cns!1pd9F9rOlOiQSBatvHQlivdg!310.entry


评论 上一页 | 下一页

看来前辈太忙，那不麻烦了，等都做好后再把完整的ECO Diagram发给您，请您指点。

发布者 A DELPHI FAN - 10月3日 11:19




>.asp.net 2.0頓時變成了花拳繡腿

哈,No No, ASP.NET 2.0不是花拳繡腿, ASP.NET 2.0仍然需要, 只是它和ECO的訴求不同，使用ECO開發網站會讓你更深入的思考設計架構，因為ECO免除了你自己需要處理的許多細節．

发布者 GordonLiWei (http://spaces.msn.com/members/GordonLiWei/) - 10月3日 9:51




总结一下是：
1 某些Forum只对某些Member开放；
2 某些Member允许进入某些Forum，但只可以浏览Topic而不能回复，或者不能发表新Topic；
3 对于某一篇Topic，可以不让某些Member浏览、或者阻止其进行回复，而同时不限制其它Member。

也琢磨出一两个可行方案，但总感觉有点拖沓麻烦。

您Blog写硬点最好，至少我的朋友和同事都认为中国程序员很需要这样的Blog，不是那些记今天吃了什么、玩了什么的Blog。

发布者 A DELPHI FAN - 10月2日 17:59




前辈：
您建的TRole类是做什么用的？
这些天学生一直在考虑如何用ECO实现“权限”而没有结果（也是用来做ASP.NET论坛）。想实现如下功能：
某些Forum只对某些Member开放；
就算某些Member允许进入某些Forum，但只可以浏览Topic，不能回复、或者不能发表新Topic；
还有，对于某一篇Topic，可以不让某些Member浏览，或者阻止其进行回复，而同时不限制其它Member。
希望您能帮学生想出一个好的设计，估计您思考出来用不了一分钟吧。
谢谢！

发布者 A DELPHI FAN - 10月2日 17:54




感謝李大師的誇獎.看了此文,又感受到其層次的不
同.asp.net 2.0頓時變成了花拳繡腿.哈,層次上差太
多了.之前只做過簡單的ECO範例,要做出較為深入的
東西.實在有點困難.對MDA的簡單觀念只有感覺好
像是規劃思考上的OO,還有利用XML當中介做到無關
資料庫的能力.另外OCL也是很漠生的東西,感覺好像
是另一套SQL語法..還有UI如何達到客製化的需求.
總之,還是粉模糊.看來要加把勁了~~到google上到處
打打ECO,ECOII,ECOIII,MDA,OCL......


发布者 CsharpvsDelphi (http://dotnet.vcl.com.tw) - 10月2日 13:10