與機房收費系統的再一次相處（.NET版）：

標籤：datagridview   style   使用   strong   檔案   資料   io   問題   

        機房收費系統個人重構的尾巴，也就是到了整體總結的時候了。師傅的每一次驗收都會有太多的收穫，自己暴漏的漏洞也越多。

        首先，說說時間。有史以來，覺得最高效利用時間的一次，這和師傅的指導和督促是拖不了關係的。正直專業期末考試的那個月，時間抓起來就稍微有點費勁，但是，做好規劃，還是覺得沒有那麼忙。因為在開始之前，師傅就給規定了時間，說什麼內容多長時間內完成。每天都有自己的計劃，要完成幾個表單或者是畫多少圖，早就找米老師談過時間管理的問題，只有這時才深有體會。有這樣的好師傅管著就好好學習，如果師傅不管了那豈不是又要回去。所以自己要養成自己管自己的習慣，提前做好計劃。

        可能是每天都在趕著進度，完成該完成的內容，所以忽略了細節，當師傅第一次給看的時候就出現了很多細節的東西沒有做。主要是：

      

        資料庫的設計

1、E-R圖：

        要嚴格按照E-R圖的標準來畫，注意實體之間的關係。

2、符合三範式

        也許你會認為胡楊版資料庫有一些冗餘，像是充值和退卡表既有學號又有卡號，如果是一個卡號的充值記錄，就要重複的查出持有該卡的學號。我們完全可以去掉學號，當查詢卡號的時候自然就標識了該卡的學號（除了一個學生有多張卡，我設計的是一個學生只持有一張卡）

3、注意主外鍵關係

        當關聯的表刪除資料時，我們要考慮的是不是破壞了這種關係，這時我們可以應用觸發器或者預存程序。

4、預存程序天使還是魔鬼

        當涉及到複雜的SQL語句時，由於沒有使用多觸發器或是預存程序，因為新鮮又節省了麻煩，還解決了問題，這樣提高了我們的效率。但是使用是不是有弊端呢？

        預存程序主要是對後期的維護增加了困難。當發現某個預存程序似乎錯了，或者不滿足新的業務需求，沒有人敢修改他們，最好的辦法是：再加一個新的。這樣儲存哦過程的數量越來越多，越來越難以命名——函數難命名不是編碼的問題，而是涉及的問題。於是，在項目運行兩年以後，還是難以形成一個優質穩定的業務開發平台，人們還在研究資料表、類型……

         說到這裡，我們應該得出結論。預存程序是不好的。因為我們自己做的系統，等師傅驗收之後就安靜的放在自己的電腦裡，沒有人會再去理會它了。但是一些大的項目就不同，需要時時的維護，而且後期的維護會更加的重要。

         但是如果我們有這樣的需求：資料庫中有大量的即時運行資料，需要定期把這些資料進行簡單的行列規整，放到另外一個資料庫中做分析統計之用。在這種情況下我首選預存程序。預存程序應該是處理“資料”，而不要處理“業務”。並且極大的減少了IO消耗，真正的體現了它的效率優勢。

      

       使用EA畫uml圖

1、總體架構（包圖）比較重要

         這是理清這個系統的邏輯結構的第一步

2、三層的劃分的標準和粒度

        有些人是按照功能分，有些人是按照表的劃分。當然各有特色。

當你B層類的劃分粒度太細的時候就會顯得B層很臃腫，幾乎是一個類一個功能，這樣就沒有了邏輯判斷一說。但是劃分粒度小的話，又會覺得B層劃分功能不全。

3、面板模式是不是可有可無

          我一直知道為什麼加面板模式，我也一直不知道為什麼加面板模式。當一個介面用例比較多，需要執行個體化N個商務邏輯層，才能一一實現，那麼不如就建立一個外觀，將商務邏輯層的類進行整合。當U層只需要執行個體一個外觀類，就能全部實現。但是一個才表單如果只有一個功能，那麼面板模式就真心多餘了。還有就是外觀層是不應該出現邏輯判斷的，因為它畢竟不是邏輯層。

        所以外觀層應該是在需要的時候有，沒必要的時候無的（個人觀點）

4、圖的注釋

        讓師傅看圖的時候，師傅說把注釋都加上，我說我覺得都能看得懂吧。她說過幾天你就看不懂了。於是我聽話的把注釋都加上。果然有的沒有加註釋的想起來是什麼功能的時候是有些費勁的。有人說過好的代碼注釋會佔到50%。看一個編程人員的水平就要先看他的注釋。這是一種習慣，一種態度，一種為人民服務的思想。

      

        EA使用的技巧

          聽了一個師哥的話才知道原來EA是如此的強大，我又是多麼的渺小。EA可以匯入VS代碼，這些相信大家都知道，當然EA還是可以設計資料庫直接匯入的資料庫的表，具體到一個欄位等。介面的實現等，當我們沒有嘗試過的都覺得很強大，當時聽完了就覺得自己對它的認識真是一知半解。

      

        系統本身

1、注重實現功能，忽略了細節

（1）、輸入框提示名字，不能只是一個MsgBox

（2）、同一個使用者不能同時登入系統值班

（3）、一些輸入框的輸入限制

（4）、DataGridView表的一些注意事項

2、返回實體與返回DataTable

         簡單的說下區別，返回DataTable自然是簡單好理解的，但是這恰好違背的解耦的思想，三層之間通過DataTable來傳遞資料，前一層調用後一層的資料需要知道DataTable裡面資料欄位的名稱。這樣當一些牛人通過你的錯誤提示會嵌入到你的資料庫中。這是很不安全的。返回實體就不一樣了，三層之間通過實體通訊，因為每一層只要知道實體的名字就可以了，不要知道具體的欄位名稱。當然返回泛型集合也可以直接和GridView直接綁定資料來源。

3、一些自身控制項的使用

        在.net架構下有許多控制項不需要安裝，這樣達到了很好的複用效果，應用平台也廣泛起來。

4、注釋的重要性

        包括標頭檔注釋（可以預先定義）、程式碼片段注釋，特殊語句的注釋等。第二次提到了注釋，可見注釋的重要性。這是讓一個人讀懂你代碼的關鍵。

         沒想到一口氣總結了這麼多，沒有圖沒有真相，總之全是文字。當自己敲出了分層的系統時開始了物件導向的征程，還是會為自己鼓一次掌的。一個月的時間匆匆而過，可以說每一次的相處都會有太多的收穫。編程仍在繼續，即將迎來機房收費系統的合作版，期待中……