MVC設計模式

標籤：style   使用   資料   代碼   sp   on   c   工作   時間   

在介面架構中，使用MVC的設計模式是最合適方式。為什麼這樣說呢？因為M是model的縮寫，就是表示模型意思。模型就是演算法，商務邏輯，商業表示。這個是經常會變的，比如像銀行開發一個超市積分系統，對不同來店刷卡的人員給不同的積分，這個是隨著不同的時間會變化，像中秋節時購買月餅就可以多增加積分，這個變化就表現在模型上。V就是view的縮寫，也就是視圖，對使用者來說就是介面。介面在一定時間內是穩定的，但隨著使用者需求變化就會產生更多的介面。比如使用者一開始可以看到資料列表顯示就已經很滿足了，當他們用過一段時間之後，就會想能否提供一個圖形來描述資料呢？這就是提出對介面的要求，也就是多視圖。也就是說，一份資料之後對應多個視圖，多個視圖從不同的角度去瞭解資料。有了模型，還有了視圖，就已經可以實現資料經過商務邏輯處理之後在視圖上顯示出來，基本上就是完成了整個軟體的需求。但是使用者對軟體的要求，不但能看到，還需要互動。比如看到曲線時，想放大一點看到細節，那麼就需要控制了。控制部分就抽象為Controller，縮寫就為C。到此，MVC三者的職責就非常清楚，M描述資料邏輯處理，V表示處理之後的資料顯示，C接收使用者控制，並且把不同的控制傳遞給M或V。它們之中，最特別的就是M與V是沒有直接的聯絡，商務邏輯處理不會在意介面是怎麼樣的呈現的，它只是實現最佳化演算法，或者最複雜的商務邏輯；反之，介面也不需要關心資料是怎麼樣處理的，只管根據使用者需要而顯示，同時多個視圖都來源於同一份資料，因此也保證多個視圖的顯示是一致的。

有了上面的概念之後，就要實踐了，只有實踐才可以對理論進行理解，並且理解得更深入。特別在軟體開發工作上，沒有編寫代碼，只看理論，就像站在岸上學遊泳，永遠學不會遊泳的。因為人在水裡與岸感覺差別很大，水的密度比空的密度不是一個數量級大，而差別特別大。因此，憑空想像是不會得到實際的感受。在編程方面，也是一樣，如果不親手寫代碼，是很難體會到想像與實現之間的差距。往往有人說，像這個功能不就幾行代碼，花兩三天就可以做出產品了嗎。其實他所說的產品只是一個針對目前情況實現的示範產品，而不是實際可用、可維護、可複用、可測試的產品。一個軟體產品在他們眼裡只是著重點是可用性，而不考慮可維護、可複用、可測試。可維護是一個重要的指標，如果不能維護，一個軟體產品很難成功，因為一個軟體產品使用周期是很長的，10年是算短的，在這10年內，不同使用者加進來，以及競爭者的出現，對軟體產品進行升級就是成為常有的事情。怎麼樣讓軟體產品更新更快，還能對舊使用者進行相容，還不讓越改就越多BUG出現，這是一個有難度的事情。如果代碼不考慮可維護性，就更加成為不可能完成的任務。可複用性就是節省軟體的開發成本，這個比較關鍵，因為軟體的開發效率就決定產品的定價。也就是決定了招標時，你的產品是否被中標的關鍵因素，一般在價格方面都起到50%以上作用。可測試就是軟體的品質了，以及軟體是否可維護的一項指標。因為一個軟體產品開發持續達到10年，每一個月更新了，還要相容舊的產品、舊的使用者，那麼怎麼樣保證相容舊的產品呢？只能針對舊的產品進行迴歸測試，這個迴歸測試，如果是人工的，顯然不全面，也不著實際。因此，自動化的測試是必然的選擇，也只有自動化測試才可以更全面地測試，確保產品方方面面都已經符合原來的規則。並且自動化測試比人工來說，也更有效率，足以降低成本。

MVC設計模式