機房收費系統是我們在提高班做的最多的一個系統,通過一遍遍的做這個系統學到了很多東西。
重構是用三層和設計模式做的
一、包圖
U層主要是放介面資料的輸入和介面的顯示情況;B層主要放商務邏輯,系統的邏輯處理;D層就是資料庫的訪問,去實現介面層的方法;SqlHelper是助手類,對資料庫的操作,增刪改查;外觀類就是重整一下B層類的結構,讓U層和B層之間的耦合度降低;抽象工廠是讓B層和D層的耦合度降低,隨便換一個資料庫只需要修改D層和設定檔就可以了,別的層不需要動。
我開始做的時候沒有用SqlHelper類,D層的每一個類都有用到資料庫的串連,增刪改查,既然每一個類都要寫,為什麼不拿出來,這樣就不用反覆重複了。
二、時序圖
下面是我畫的時序圖的曆程:
第一次畫的時序圖:
第一次的畫的時序圖,生命週期很亂,沒有搞清楚,而且邏輯也沒有弄清楚。
最後一次畫的時序圖:
最後一次畫的時序圖相對來說更成熟一點。
三、技術問題
組合查詢 我的組合查詢一開始做的時候就想寫在預存程序中這樣拼接字串就寫在了預存程序中,很方便簡單,但是這樣想,在做的過程中由於在預存程序中的符號還有文法不是很熟悉,總是調不出來,於是就放棄用預存程序,打算在合作開發的時候好好研究研究。
路徑問題 一開始做系統的時候,放設定檔,我自己想應該是放在D層,可是D層沒有找到添加方法,反而在U層找到了,於是上網查了一下說是U層是主程式集,系統是從U層起來的,所有的dll放在U層的Bin中。啟動並執行時候D層出現問題,是使用相對路徑請確保目前的目錄是正確的。這時要把D層的路徑改了,改到U層的Bin中,這樣D層的dll就會自動拷貝到U層的Bin中。這也遵循了反射的原則:一切一U層的Bin檔案夾的dll為中心。如果說是將D層的dll拷貝到U層的Bin中,雖然這樣是可行的,每次都要拷貝,但是不能保證每次D層修改後重建dll之後都不忘記拷貝到U層Bin中。
預存程序中加事務 這次加了預存程序,沒有加事務,但是卻出現了一個問題,就是在執行預存程序中的語句出現錯誤時的情況沒有處理,這時不要忘記加事務,一旦有問題出現,就會復原,也就是說當第一個表修改完,可是第二表改修出現了異常而沒能修改的情況下,第一個表和第二個表都要回到未修改的狀態。
這次重構是一條線一條線寫的,合作的時候要一層一層的寫。學習是一個過程,在這個過程中我們每天都在進步,每天都會學到不一樣的知識。未來,加油!