MVC設計模式
在界面框架中，使用MVC的設計模式是最合適方式。為什麽這樣說呢？由於M是model的縮寫，就是表示模型意思。
模型就是算法，業務邏輯。商業表示。
這個是常常會變的，比方像銀行開發一個超市積分系統，對不同來店刷卡的人員給不同的積分，這個是隨著不同的時間會變化，像中秋節時購買月餅就能夠多添加積分，這個變化就表如今模型上。
V就是view的縮寫，也就是視圖。對用戶來說就是界面。
界面在一定時間內是穩定的。但隨著用戶需求變化就會產生很多其它的界面。比方用戶一開始能夠看到數據列表顯示就已經非常滿足了，當他們用過一段時間之後，就會想是否能提供一個圖形來描寫敘述數據呢？這就是提出對界面的要求，也就是多視圖。
也就是說，一份數據之後相應多個視圖，多個視圖從不同的角度去了解數據。有了模型。還有了視圖。就已經能夠實現數據經過業務邏輯處理之後在視圖上顯示出來。基本上就是完畢了整個軟件的需求。可是用戶對軟件的要求。不但能看到，還須要互動。比方看到曲線時。想放大一點看到細節，那麽就須要控制了。控制部分就抽象為
它們之中，最特別的就是
M與V是沒有直接的聯系，業務邏輯處理不會在意界面是怎麽樣的呈現的。它僅僅是實現最優化算法。或者最復雜的業務邏輯；反之。界面也不須要關心數據是怎麽樣處理的，僅僅管依據用戶須要而顯示。同一時候多個視圖都來源於同一份數據，因此也保證多個視圖的顯示是一致的。有了上面的概念之後，就要實踐了，僅僅有實踐才幹夠對理論進行理解，而且理解得更深入。特別在軟件開發工作上，沒有編寫代碼。僅僅看理論，就像站在岸上學遊泳，永遠學不會遊泳的。由於人在水裏與岸感覺區別非常大，水的密度比空的密度不是一個數量級大，而區別特別大。
因此，憑空想像是不會得到實際的感受。在編程方面。也是一樣。假設不親手寫代碼，是非常難體會到想像與實現之間的差距。往往有人說，像這個功能不就幾行代碼。花兩三天就能夠做出產品了嗎。事實上他所說的產品僅僅是一個針對眼下情況實現的演示產品。而不是實際可用、可維護、可復用、可測試的產品。一個軟件產品在他們眼裏僅僅是著重點是可用性，而不考慮可維護、可復用、可測試。
可維護是一個重要的指標。假設不能維護，一個軟件產品非常難成功，由於一個軟件產品使用周期是非常長的。10年是算短的，在這10年內。不同用戶加進來，以及競爭對手的出現，對軟件產品進行升級就是成為常有的事情。
怎麽樣讓軟件產品更新更快，還能對舊用戶進行兼容，還不讓越改就越多
假設代碼不考慮可維護性。就更加成為不可能完畢的任務。可復用性就是節省軟件的開發成本，這個比較關鍵，由於軟件的開發效率就決定產品的定價。也就是決定了招標時，你的產品是否被中標的關鍵因素，一般在價格方面都起到
50%以上作用。可測試就是軟件的質量了，以及軟件是否可維護的一項指標。由於一個軟件產品開發持續達到10年，每個月更新了。還要兼容舊的產品、舊的用戶，那麽怎麽樣保證兼容舊的產品呢？僅僅能針對舊的產品進行回歸測試。這個回歸測試。假設是人工的，顯然不全面。也不著實際。因此，自己主動化的測試是必定的選擇，也僅僅有自己主動化測試才幹夠更全面地測試，確保產品方方面面都已經符合原來的規則。而且自己主動化測試比人工來說，也更有效率，足以減少成本。MVC設計模式