今天在做庫存管理程序時,原以為簡單的倉庫盤點,卻發現要支持錯誤修正時,要增加很大的工作量。原因在於原來的開發使用“事務腳本”模式進行開發。原來只要支持:凍結,盤點,解凍,這幾個動作,為這內個動作各寫一個事務腳本也就簡單解決了。當要支持編輯及修正盤點數據時,一般使用記錄修改模式進行開發,這樣編輯界面會比較友好,此時因為涉及歷史數據的修正, 平常我常用這兩種方式解決:1、使用觸發器方式來實現歷史記錄的同步修改。2、用批更新方式放入一個事務中完成。但這樣對於權限操作來說,不好定義。
這次,我延續“事務腳本”的思路,將編輯及修正盤點數據的動作歸納為幾個操作:解凍歷史數據->重新修正當次盤點結果->修正結束重新凍結 , 這樣就需要增加兩個事務腳本(解凍歷史數據,修正結束重新凍結)及一個編輯界面(重新修正當次盤點結果),避免了使用觸發器容易引起其他模塊的異常,用批更新方式未能定義修正過程及權限上的混亂。編輯界面因為使用記錄行修改模式進行,重用“記錄行修改模式”就能很也地完成工作。
在關系式數據庫開發中,因為開發工具(.net 或 vcl )的原因,很難使用“領域模型”來進行開發,因為那樣工作量太大了,規劃好數據及其操作後,使用數據集模式結合事務腳本來開發,是比較適合的方式,也能達到良好的代碼重用效率。
注:是否允許修正歷史封存數據 ,那是另外一個話題 ,因為要支持允許回溯修改3個月內的歷史數據,才有這次程序的修改。也認識到以前那種規則:一旦封存不許修改並不是一成不變的,雖然修改影響到很多很多問題,但檢驗的標准是實踐,而不是其他。錯了就是錯了,不許改正只許修補的庫存理念是不行的。