所以，每個datamodule應該只放乙個物件所需的tdataset，當產生instance時，可以克服以上的問題，這是以物件的觀點來看，可是當我們用資料的觀點來看時，還存在一些問題，在關聯式資料庫底下不同table之間資料要如何關聯？我們第乙個反應是使用tfield的物件，用lookup欄位來訪問，可是當我們用lookup去訪問資料，可能必須去存去另乙個datamodule的tdataset，這樣還是一樣會把datamodul糾纏在一起 (如下圖)。delphi rad的設計一直存在兩種正負面的評價，原因是在要兼顧視覺化設計的優點，又要符合物件導向設計的方法，往往有所衝突。本文主要探討delphi
在現有框架上如何實現商業物件的設計，及應該注意一些的設計要領。
商業物件的目的就希望將系統元件化，並達到重複使用的目的，以降低軟體開發成本，在使用上我們又希望維持delphi
這種視覺化的設計。由於受限於delphi tdataset 的資料模型，許多協力廠商，在資料的持續層上開發r-o maping 以便讓商業物件的開發更加容易，以下列出一些商業元件廠商所開發的相關產品﹕
boldsoft co.
instantobjects™
tiopf
本文則是探討在現有架構下，如何達成商業物件的設計。
以物件的裝封，繼承，多型的特性而言，無疑的tdatamodule 都符合這個要件，同時tdatamodule本身可以結合並管理tdataset物件，所以用tdatamodule來發展商業物件，是乙個很好的選擇，，，另外tdatamodule 也可以包裝程成com的物件，供其他語言使用。
但是我們常見到一些專案的開發，把全部tdataset 擠在乙個datamodule中，我覺得這不是乙個很好的設計，理由如下﹕
針對持續層資料訪問的問題，以下提出兩個解決方案﹕
delphi
的tfield 的物件，是連線到實體資料的功臣，也是讓我們可以輕易的鏈結資料的關鍵物件。tfield 提供四種資料鏈結模式﹕
fkdatafield represents a physical field in a database table ﹕根據資料表的字段取代現有字段
fkcalculatedfield is calculated in an oncalcfields event handler﹕在執行期間由資料集的oncalcfields event 處理程式計算的數值
fklookupfield is a lookup field.﹕執行期間根據所指定的條件從特定的資料集取得數值
fkinternalcalcfield is calculated but values are stored in the dataset.﹕顯示執行期間，由使用者端資料集計算的數值。與fkcalculated field 不同的是fkinternalcalc field 字段計算的數值是儲存在資料集中，並可以像使用者端本身的資料一樣來訪問。
fkaggregatefield represents a maintained aggregate in a client dataset.﹕顯示一組記錄內資料的彙總值。
其中fkinternalcalc及fkaggregate 兩種模式，只能在tclientdataset使用。
以上兩種解決方案，很顯然第二個方案，在資料訪問方面，具有很大的彈性。tclientdataset 在寫回資料時擁有自己的方法，因此可以針對不同tdataset進行操作，也就是可以面對不同資料庫。同時利用資料虛擬層，去穩定實體層的變動性，虛擬層可以用資料庫的view 來設計，由於view 可以跨越不同table ，同時變成標準介面與datamodule結合在一起 ，所以之前所說loopup 字段問題也就迎刃而解。
使用ado資料庫引擎去鏈結資料庫時，tclientdataset 有一部份的資料搜尋功能無法正常使用，包括locate ，loopup ...等方法 , 這是由於tclientdataset 無法處理unicode ，所以中文字碼，無法搜尋。
(三)資料庫與物件的對應關係
在傳統的系統分析方法，我們是以資料流配合關聯式資料庫進行系統分析，當資料規格設計完成，系統就配合使用流程及資料規格進行設計，沒有以物件為中心的觀點進行分析，將很難把物件對應到實體資料。所以以下列出幾個必須改變的觀念。
( 注: 建立以物件為中心的設計系統觀點 )
以商業物件對應關聯式資料庫，不外乎三幾種關係﹕
乙個客戶物件，可能對應乙個table，乙個異動單據可能對應乙個master-detail table，乙個系統使用者有可能沒有對應的table，所以不能用關聯式資料庫去反推對應到物件，而是必須將過分析，確實找出系統物件，以物件的觀點來建構資料庫。在使用需求的捕捉方面，使用uml(統一模塑語言)是乙個不錯的選擇，市場上也有許多支援的工具可供使用。
以物件為思考的系統，實體的資料主要是配合物件做資料訪問，而非針對輸出入的資料去回應，因此再系統分析時，如何找出適當的物件，是乙個很重要的課題。許多傳統的系統分析仍停留在以資料流為中心的想法，這種觀念無助於開發商業物件。
(四)物件類別的設計
商業物件可以從tdatamodule 繼承下來，先產生乙個tmasterobject，將各物件共同的屬性及方法設計在這個物件，再從這個物件，繼承產生各類物件，如下圖所示﹕
介面設計時，我們仍可以在設計期間從各類別透過tfield取得資料，享受delphi 的視覺化的設計優點，而各類別之間的合作，只有在執行期間，再進行結合，譬如乙個單據類別，可能需要傳送訊息給庫存類別，那麼可以在資料post 回資料庫之前，傳送乙個訊息給庫存物件，由庫存物件負責更新庫存，讓物件之間的責任清楚，系統會更有條理。
在面對不同的專案時，可能要進一步分析，究竟是個別獨立設計乙個架構，或者是在同一架構中，改寫部分的物件功能，以達到重複使用的目的，這部分有賴於使用analysis pattern做進一步的分析。class ( 類別 ) 是靜態的結構，當我們依照class 建構乙個物件時，產生乙個instance( 執行案例 )，物件與物件之間的合作關係，是在產生執行案例之後，不可以將class 及instance 兩者觀念搞混。
當我們從delphi 的元件盤取產生乙個元件，這個元件是乙個class ，只不過rad會自動幫我們去建構物件，產生執行案例，以致讓使用者誤以為class等於instance。rad隱藏了許多複雜的動作，讓我們易於使用，但也同時混淆了我們使用物件的觀念。
(五) 結語
從理論到實作這一條路，存在有一些迷失，這個迷失其實也是上述所談的，有些物件觀念不夠清晰，碰上實作時，不知如何去應對問題。另一方面，在實作時，我們也才真正認識，到底是那些觀念不夠清楚，所以我強烈的建議各位找乙個簡單的case 去試試看，把所學的物件理論，去套用看看，問題馬上浮現出來。到目前為止 ，很少有人談論到delphi 在商業物件實作技術上的問題，這不代表沒有問題，而有可能根本不知道問題在哪裡，而只是沉迷在rad的快速設計，一方面享受，也一方面受害。
rad並沒有害我們陷入困境，只是我們還停留在程式性的程式設計思考框框而不自知，這也是因為我們物件觀念不夠清晰，而rad正考驗著我們的物件觀念是否夠堅強，用rad但不要被拖著走，這也是我想說的一句話。
發展商品經濟的遠見 領導真是英明
摘自 第三，當時，我國改革開放剛剛起步，雖然經濟體制改革的目標尚未確定，處在 摸著石頭過河 階段。但有經濟學家認為，高度集中統一的計畫經濟已經走到了死胡同，必須進行改革，發展商品經濟。而發展商品經濟，人們的價值取向和婚育觀念就會發生變化。伴隨而來的，是未婚先育 流產比以及離婚率公升高等現象的增多。因...
delphi 指標使用
指 針 指標的動態變數 1.定義指標型別 在turbo pascal中，指標變數中存放的某個儲存單元的位址，即指標變數指向某個儲存單元。乙個指標變數僅能指向某一種型別的儲存單元，這種資料型別是在指標型別的定義中確定的，稱為指標型別的基型別。指標型別定義如下 型別名 基型別名 例如 type q in...
DELPHI 指標使用
delphi裡自己管理記憶體的兩對函式 new dispose 和getmem freemem 大家都認為，c語言之所以強大，以及其自由性，很大部分體現在其靈活的指標運用上。因此，說指標是c語言的靈魂，一點都不為過。同時，這種說法也讓很多人 產生誤解，似乎只有c語言的指標才能算指標。basic不支援...