DelphiMIS開發架構心得一關于開發工具.數據庫比較流行的是Delphi+Sqlserver.Delphi的好處我就不多說了.大家可以在網上找到很多.至于選擇Sqlserver的原因,一是對中小型企業來說,Sqlserver的性能也還可以,價格相對于oracle來說要便宜很多.再就是Microsoft的東西在易用性方面的確下了不少功夫.幫助資料齊全,本地化的語言也做得好.再加上目前國內的版權意識不是很高.所以選擇Sqlserver的人很多.其實開源的firebirdsql,postgresql等等也還是很不錯的,又不用花錢,但在國內用的人很少.二關于數據庫連接層.用Borland的BDE還是MS的ADO,到底哪個好.(新的dbexpress俺沒用過,不敢發言).其實BDE和Ado都很優秀.BDE因為不是windows的東西,要另外安裝,比較麻煩些.Ado則是高版本windows內置的.目前來看,用ADO的人數遠遠大于用BDE的.但BDE有一個好處,它的更新可控制性要比ADO強.它有一個UpdateSql組件,可以自定義更新的三種sql語句.這個優點已經被ADO.Net吸收了.三關于三層還是兩層的問題.看了一下國內和臺灣的幾家較有名氣的軟件公司.三層是大勢所趨.但目前做兩層的還是多數.國內神xxx的Erp軟件,臺灣統x的軟件用的是三層,同樣用的是delphi的開發工具.東莞有家小軟件公司做的進銷存也是三層.都用的borland的midas技術.國內的速xErp是個假三層的,怎么說呢.它有個后臺”應用程序服務器”在運行,但只起到客戶端的連接監控作用,商業邏輯仍然是放在數據庫后臺的.所以說是假三層.四關于面向對象與關系數據庫的矛盾問題.網上討論很多.牽涉到三層的設計問題.牽涉到對象感知組件的問題.國外也有很多討論.解決的方式大致有兩種,一種是不用或者少用數據感知控件,自己寫代碼控制數據的變化控制與輸入輸出.這樣可以封裝實體類.以實體類或者實體類集合來工作,另外創建功能類,在功能類中寫方法操縱實體類.不過這樣一來工作量很大的.需要有object/relational自動映射工具幫助實現.第二種是用數據感知控件.并且以dataset為中心.需要自己創建的實體類很少.商業邏輯還是要寫sql語句,不管是放在什么地方.就是存儲過程也不過是預編譯的sql語句集合.這種方式比較大眾化,對部分程序員的要求可以放低些(不要誤會說這種方式的水平低).而且可以配合midas技術使用.國內神州數碼的erp就是用這樣做的.五.關于midas技術中的商業邏輯怎樣安排的問題.臺灣李維的書也將midas,也講商業邏輯.但他好像沒有怎樣用midas實現商業邏輯(也許李維講了是本人沒有看到.).其實這個商業邏輯很簡單,就在那個DataSetProvider的beforeapplyupdates和afterapplyupdates中自己寫好了.在這里要檢查哪些值改變了,改變量是多少,針對這些改變量,我還要改變數據庫中其他那些表的哪些記錄的哪些字段值.舉個例子.以開一張銷售出貨單來看.該張銷售單賣了A產品100個,B產品50個,那么要在庫存現存量中減去A產品100個,B產品50個,在財務的應收帳里加上這個客戶本張單的欠款.具體要看你的數據庫設計和數據流程.通常的erp軟件里面商業邏輯很復雜,往往要改另外5,6個表以上,包括增,刪,改都有可能.通常在數據庫中寫好storeproduce,然后在中間層調用.這種情況基本上不用寫觸發器(trigger).對應觸發功能是由應用服務器完成的.但如果沒有用midas,是兩層結構.往往免不了寫trigger.是否另外寫storeproduct看情況需要.一般不推薦在客戶端寫商業邏輯,一方面編程難度加大,這種方式對用戶的數據操作必須及時跟蹤.另外修改了商業邏輯必須重新編譯代碼.不像在數據庫端改了觸發器即時生效,而且通常客戶端較多,而數據庫服務器只有一個,不存在版本更新的分發問題.六關于主從表,英文通常叫master/detail.做數據庫通常免不了要用主從表.BDE和ADO都支持主從表.A就更方便了.此處不談.不過要注意主從表的增加一定要放在同一個事務下主從表的構成有兩種方式.一種是query組件,設置deltaildatast的datasource屬性,然后在detail表的sql語句中用where語句關聯主表.如select*fromdetailtablewheredetailtable.masterid=:id,id為主表主鍵.另外是用adodataset,從表select語句如常,但設置其datasource為對應主表的datasource,,并設其masterfields屬性為主表的主鍵.注意在保存數據前主表beforepost事件中要開啟事務,取消主從關系,在afterpost事件中保存從表數據,提交事務,恢復主從關系.具體原因我還不清楚.七關于dataset中的lookupfield的問題.一般好的數據庫設計要符合范式.就是盡量減少數據庫的冗余.想深入研究得學<數據庫原理>.舉個例子.一個銷售訂單.單據上有客戶編號,客戶名稱,客戶地址.交易金額等等.上面列出字段都是要顯示和打印出來的.但實際上我們在關系數據庫的訂單主表中跟客戶相關的就只保留一個客戶編號字段.其他字段如客戶名稱,客戶地址都不要在訂單表中保留.但是前面說了我要顯示啊,怎么辦.有兩種方法.一種是在某出地方另外放一個讀取客戶表的dataset,然后在訂單主表saleordermaster中加幾個類型為fklookup的查找字段,設好他們的屬性指向customerdataset相關字段.這種方法比較常用.還有一種方法是數據庫的設計不變,但在saleordermaster這個dataset中使用連接語句比如select訂單主表.*,客戶表.*from訂單主表訂innerjoin客戶表客on訂.客戶id=客.客戶id.可以一次join幾個表,并不限于兩個.對于這種join后的表,修改后保存有些特殊規定.一般只能修改其中一個物理表.此處我們修改的是訂單主表.對客戶的修改,屬于基本數據,可以放在另外的地方.但怎樣讓程序知道我們要修改的是訂單主表而不是客戶表了.對BDE和ADO.處理方法不同.bde中可以設置saleordermaster這個dataset的updateobject組件(是updateSQL類型),在其中自己寫更新語句,只更新訂單主表即可,客戶表忽略.對于Ado,一般因為相對于客戶表,訂單主表是從表,客戶表是主表,ado有一定的只能,它會修改從表而保持主表不動.如果有問題,則可以明確指出只修改訂單主表.用以下語句:perties[‘uniquetable’]=’訂單主表’指明即可.另外這種方式還有一點要注意.如果新增一條記錄,客戶表的客戶id是可以填,但客戶名稱和客戶地址它不會自動去后臺數據庫自行查找再填充的,你必須在dataset的afternew事件中自己想辦法把他們填到當前記錄的相應字段中.可以自己定義一些函數專為此用.比如getcusterombyId()等等.八.關于sqlserver數據庫的identity問題.我自己也曾困惑了很久.單純對于數據庫來說.有個identity字段是比較方便的.但是結合起前端開發工具來說.用不用,怎樣用,就要仔細斟酌了.我見過幾個軟件,臺灣統xERP,大陸速xERP,都是用的sqlserver.都不用identity字段.他們還是用整數做Primarykey,但不是identity.這種安排的一個重要原因是主從表的同步問題.因為identity的值做主鍵必須等存盤成功后才知道到底是多少.而從表保存時就需要知道主表的primarykey.我在第六部分說的”斷開主從關系”可能也與此相關.在微軟的體