动态数据模组.docVIP

Delphi Databases: Dynamic Datamodules at Runtime 作者：Charles E. Weindorf（Charles.Weindorf@） 翻譯：Justim（justim@.tw） 有個農夫的箴言是這樣說的：「不要試著把十磅的馬鈴薯放進只能裝五磅重的袋子裏。」雖然這是個常識，但當我主持的一個Delphi的project時，甚至在袋子中放超過了十磅重的馬鈴薯。在這個project中，小組的程式設計師必須在多數不同的表單(form)中存取超過 70 個資料表格。使用一個主要的datamodule去管理 70 個表格，此datamodule成為所有表格的交通警察，並且操作這些資料的商業邏輯。但在這種架構中，由於任一個form使用到的資料表的數量大概是2到20個，所以在datamodule中會有許多的query及datasource物件是閒置不用的（這至少值五磅重）。然而，當我們嘗試著將這巨大的datamodule分割成數個較小的datamodule時，發現各個form所用到的資料表都有所不同，而這些排列組合會變得十分的複雜，於是如何整合這些不同datamodule將成為專案發展的一個困難。在試過許多不同的技術後，我發展出了一種架構，這個架構利用一個datamodule來維護所有的資料庫表格，使其可以保有集中管理的優點，但在執行時期又不耗資源的技巧。 下面的文章將描述delphi的程式設計師如何駕馭query及datasource的演進過程： 方法一：在每個Form上都置放TQuery/TDataSource元件（TQuery/TDataSource on all Forms） 自Delphi 1的時代以來，這個方法幾乎是任何delphi的程式設計師都會用的技巧。還有什麼比將query元件放在form上，然後設定datasource的連結更簡單的事？雖然說很方便，但在維持資料庫表格資料的一致性上，這個方式有其弱點了。在一個大型的專案裏，程式設計師無可避免地必需在許多form上放置query元件，當資料庫表格的schema有任何變動時，程式設計師必須修改form上所有相對於這個table的定義，此外，所有相關於這個query的商業邏輯的程式碼也將會四散且重覆出現在個各個form裏。 圖表 1 於是，在Dehpi 2，最主要進步在於… 方法二：將元件置於datamodule中（Components in Datamodule） Datamodule是個很方便可以讓程式設計師集中管理專案中所有的query及datasouce元件的地方，此外，我們也可以將相關的的商業邏輯程式碼置於此處，達到集中管理的目的。在多個form中使用一個單一的datamodule會造成管理上的困難，當使用者在不同的form間切換時，程式設計師必需確保不同form間資料的一致性。雖然單一的datamodule架構可以節省資源及記憶體的耗用，但是程式設計師卻必需撰寫額外的程式碼來確保在每個form中的資料都是正確的。 圖表 2 方法三：多個datamodule架構（Many Instances of Datamodule） 為了確保form及datamodule間資料的一致性，我們可以利用「每個form都擁用自己的datamodule 實體（instance）」的架構（譯注：請讀者看圖三，所謂「自己的datamodule實體」是指每個form生成時，會建立一個私有的datamodule，而這個form中所有用到對資料庫的處理，都是參考到這個私有的datamodule。但就以巨觀的角度來看，這些datamodule其實都是一樣的，這也是為什麼圖三作者會這樣畫的原因，請讀者和方法四做個比較後會比較明白）。而這個架構，可能是個在記憶體使用上最沒有效率的一種方式。如同方法一，商業邏輯的程式碼將會散落而且重覆地出現在不同的instance間，此外，一樣會有不少query及datasource的元件被閒置在datamodule裏，造成記憶體的浪費。這個方法的優點如同方法二，由於其架構在邏輯上還是屬於集中式的，故資料庫的維謢及管理都還算簡單。 圖表 3 方法四：動態的datamodule架構（The Dynamic Datamodule） 我把動態的datamodule架構目標條列於下： 允許每個form的instance搭配自己的datamodule。 能裁切（tailor）datamodule中的dataset使其符合每個form的需求 將商業邏輯的程式碼由form及datamodule中給抽離出來。 圖表 4 那…給我看看程式碼吧！ 一如linux使用者所認知的，學習及為你的系統加入新的特色就是使用open source。底下的範例程