1. 程式人生 > >個人重構機房收費系統小總結

個人重構機房收費系統小總結

    個人版機房收費系統總算是完事兒了,會看這一段歷程真是感慨啊。開始的一段時間,寫著三層,感覺好難啊,當時看著三層的例項,自己也敲過了。但是總是憋不出來,總是想不出來更寫不出來。慢慢的慢慢的試著通過其他人的部落格,查資料。自己能寫出了三層的登入窗體。當自己三層寫完的時候回頭加設計模式,又是一頭霧水啊,說句實在的設計模式都不理解呢,就更別說在登入窗體中加模式了。

    在重構的時候,對於資料庫也是困難啊,對於資料酷三正規化雖然知道了,字面上是理解了。但是總是寫不出符合機房收費系統而且又符合三正規化的資料表。

    饅頭的一口一口吃,困難的一各一個的克服,看同學部落格,和同學交流,這才終於能夠走動了。

    在敲系統的後半階段,會看自己敲的系統感覺漏洞百出啊,哪兒有符合面向物件的設計,類用的是一塌糊塗。在用三層的時候加進設計模式應該能夠減少程式碼的複用以及類與類之間的耦合。

    原因分析,關於個人惰性的問題這裡就不想多說了,對於技術的問題,我寫的過程中先寫了幾條線兒,然後敲的系統感覺可以了就沒有畫圖而是一股腦的敲完了在回頭照著已經敲好的模式去畫圖。原因就出在這裡,導致在敲系統的時候沒有很好的把握好全域性觀。現在回想起來感覺除了UI層不用改生下的都需要動手術。首先說一下D層,因為有一個SQLHELPER減少了連線資料庫程式碼的複用,用一個表建立一個類來代替以前凌亂的根據窗體來建立的類。這樣就減少了

D層窗體的建立而且在通過呼叫的過程中能夠比較靈活的呼叫使用目的表。而如果按我已經敲過的系統來使用這樣針對比較小量的窗體而言比較合適(但是對於比較小軟體用到的資料表肯定也不會多,所以還是針對表建立D層類合適,說來說去我建的就一垃圾啊),對於機房收費系統事實證明鐵定不合適了。在談B層,對於B層而言相對來說就比較簡單了,無非就是呼叫D層的方法,有些窗體需要使用多個數據表,這些通過外觀模式的方式來減少U層與D層之間的耦合,這樣就只需要通過幾個類甚至一個類來完成U層要實現的功能了。