機房重構---咱們「重構」出了什麼？

           機房重構當即就要結束了，在這「第三個」系統結束的時候，有必要思考一下咱們重構的目的了。

          或許有人說，還有什麼目的呀，不就是編程語言換成了.Net，作出來，調完bug,能執行就得了唄。這麼浮誇的日子裏，還叫什麼勁啊？

          對於有這樣的想法的人，我必須道一聲：您（白）辛苦了 ！

          無論作什麼事，沒有一點總結性思考是沒法進步的。

          我如下的一些重構論述或者說反思性總結也存在不少不足，但願你們多多指正，在此先致謝！

          本文將從五個方面論述一下此次的重構系統，各自是系統架構、UML圖指導、設計模式應用、數據處理和麪向對象。

 

          首先，系統架構方面。

          在此次重構中，咱們都運用了三層架構，目的是減小耦合，提升系統的重用性和可維護性等各類目的。在設計中，和第一次機房的基本面向過程編程相比，咱們確實也深入的體會到了有架構的方便和易維護。

          經過加入外觀、SqlHelper、配置文件等基本輔助模塊或工具，咱們再次體會到了獨立的封裝給咱們帶來的巨大便利，從解耦到封裝，就看到了面向對象。

 

          其次，UML圖和文檔的指導。此次重點是放在了UML圖上，用例圖、包圖、類圖和時序圖是關鍵。

          包與」三層「、類圖與三層中D層和B層的設計（不一樣的分類標準，如按數據庫表仍是功能進行B層設計）、時序圖對功能運行過程的指導等都是密不可分，需要咱們必須提早細緻分析的。固然，這些都是創建在需求分析和用例設計之上的。

 

          再次，設計模式方面。

          現在爲止，應用設計模式的難點在於怎樣將系統的某個功能或系列功能相應到設計模式中。學習過程當中，能夠對各個實例理解和形象化描寫敘述出來是重點，這樣咱們才幹更好的相應到之後的系統實例分析中。

          在機房重構中，眼下我瞭解或使用的設計模式應用有：

          策略模式-對於不一樣類型的用戶實行不一樣的計費方法

          抽象工廠+反射-對不一樣的表進行簡單化切換

          外觀-在U層和B之間的外觀層，進一步解耦，使U層更具獨立性

          模板-相似的窗口不需要一遍遍反覆的代碼

          適配器-外部報表和vb.net融合

          單例-保證一個窗口不被各類new出來

          職責鏈-從通常用戶到操做員再到管理員，總有一個要解決這個問題

 

          再談談數據處理方面。

          數據處理無論何時都是一個重點需要解決的問題，尤爲是在現代大數據時代，效率和安全顯得更爲重要。在此次機房重構中，對數據庫一些功能有了更爲深刻的理解。          

          這裏說兩點。一是在經過第一次作機房的時候對建數據庫的生澀、缺少必要三範式分析的基礎上進行了第二次數據庫創建和改良。即便在系統編程過程當中，有時候仍是避免不了去動數據庫，改改字段，以彌補咱們分析的不足和暫時的靈光一現。

          二是當咱們一而再，再而三的路過標有「事務、存儲過程、觸發器、視圖」等等關鍵詞的路牌時，有必要駐足去探查一番了。存儲過程和觸發器運行方便切更符合封裝性特色，事務對系統某些」互相影響「功能的嚴格控制等特色讓咱們不得不去探索它們的長處，進而應用。存儲過程的應用如上下機、組合查詢等；事務可以考慮用於充值、結帳方面。

 

          最後，談一下系統與面向對象。

          在此次重構中，體會到了面向對象無處不在的思想長處。

          比方繼承性：管理員對操做員的繼承，操做員對通常用戶的繼承，不只明白了他們之間的聯繫，還簡化告終構。另外接口的應用也是繼承。

          封裝性就體現的不少其它了，數據封裝、功能封裝無處不在。一個良好的系統設計需要對面向對象、面向接口有着極爲深刻的理解，另外，在實際操做過程當中進行實踐更是提高咱們理解的最佳手段。

 

          總結：對於這次機房重構，還有很是多實踐上應用的不足，怎樣把這些思考經過此次重構，乃至結合下次的合做版實現，纔是對經驗最好的補充。這樣在應對如下的學習時，就可以把學習自己做爲一個系統進行完美解析和最佳實踐了。