回《【開源】EFW架構系列文章索引》
EFW架構源代碼下載下傳V1.3：http://pan.baidu.com/s/1c0dADO0
EFW架構執行個體源代碼下載下傳：http://pan.baidu.com/s/1eQCc69G
上一章《EFW架構破繭成蝶》通過講叙自己的一些程式設計經驗，有對系統架構的認識，也有EFW架構中MVC模式的由來。整個過程分為五個階段：
asp網站：做asp網站的時候根本沒有什麼系統的概念，就是幾段代碼複制粘貼拼裝成外表不一樣，功能就是那麼幾個的企業網站，哪會想到代碼的重用、維護與擴充；
桌面系統：換了家公司開始接觸CS結構的系統，知道了業務需求的重要性，經常一個功能随着業務的變化經常反複修改，這時候開始有了對代碼的思考；
三層架構：有了對原有代碼的認識，開始打破原有模式，對系統架構的認識一次質的突破，在項目中充分實踐了分層模式；
Web系統(ExtJs+Aspx)：随着技術的發展開始轉向Web系統，這是對Web系統認識的一次過渡；
EFW架構(JqueryEasyUI+HTTPHandler+Controller+ObjectModel+Dao+Entity)：隻有經曆過一些教訓，且在成長過程中不斷思考、總結，才能成就一個實用友善的架構；
本文要點：
1.MVC介紹
2.對比EFW MVC與Asp.Net MVC的優缺點
3.為什麼要使用 MVC
4.AJAX的七宗罪
MVC 是一種使用 MVC（Model View Controller 模型-視圖-控制器）設計建立 Web 應用程式的模式:
Model（模型）是應用程式中用于處理應用程式資料邏輯的部分。通常模型對象負責在資料庫中存取資料。
View（視圖）是應用程式中處理資料顯示的部分。通常視圖是依據模型資料建立的。
Controller（控制器）是應用程式中處理使用者互動的部分。通常控制器負責從視圖讀取資料，控制使用者輸入，并向模型發送資料。
MVC分層有助于管理複雜的應用程式，因為您可以在一個時間内專門關注一個方面。例如，您可以在不依賴業務邏輯的情況下專注于視圖設計。同時也讓應用程式的測試更加容易。
MVC 分層同時也簡化了分組開發。不同的開發人員可同時開發視圖、控制器邏輯和業務邏輯。
在EFW架構中：
Model：代表的就是ObjectModel、Dao和Entity
View：代表的就是JqueryEasyUI
Controller：代表的就是WebController
有很多程式員往往把架構模式和設計模式混淆，認為MVC是一種設計模式。實際上它們完全是不同的概念。架構、設計模式這兩個概念總容易被混淆，其實它們之間還是有差別的。架構通常是代碼重用，而設計模式是設計重用，架構則介于兩者之間，部分代碼重用，部分設計重用，有時分析也可重用。
EFW MVC的優點：
1.界面代碼編寫不能太靈活，aspx界面不能帶<%%>直接從背景擷取資料，aspx檔案隻有html标簽，資料請求都放在JS檔案中，達到代碼完全分離
2.開發系統一定標明一個主要的界面架構，如JqueryEasyUI，這樣界面代碼與控制器相對應，直接互動基于Json資料，并且是基于JqueryEasyUI的資料結構的Json資料；這樣就能大量簡化我們的資料結構轉換的工作量；
3.一定要利用Jquery中的Ajax向控制器請求資料，不要用其他那些亂七八糟的方式；
4.AspNetMVC有一個複雜的路由映射系統，可以非常靈活的自定義配置，而EFW中的MVC就沒這麼複雜，很簡單隻是在Url參數指定Controller和method就行了，就會将http請求調用指定控制器中的方法；
EFW MVC的缺點：
1.界面層的資料轉換隻能使用Javascript腳本來處理，不能使用動态腳本語言，這樣加大了javascript腳本的工作量，對以後的維護還是存在一定挑戰。
2.大量使用Ajax進行資料互動，不能被被搜尋引擎識别，且Ajax也存在一些弊端，請看下面的“AJAX的七宗罪”
ASP.NET MVC的優點：
1.aspx代碼可以寫動态腳本語言，有點回歸到asp那種編碼方式
2.應用程式通過Controller來控制程式請求，并提供了原生的UrlRouting功能來重寫Url。
ASP.NET MVC的缺點：
1.别扭的視圖：能不能不要讓我承擔邏輯
我個人認為，ASP.NETMVC第一個不太妥當的地方就是視圖的實作。在這個架構中，視圖是使用ASPX檔案實作的。就呈現資料這一需求來說，ASP.NETMVC下一般性的做法是：控制器負責調用Model完成資料的讀取，并将需要呈現的資料通過ViewData傳遞給視圖，并選擇某視圖呈現。被選中的視圖要負責将ViewData中相應的資料讀取、分解，然後使用一定的邏輯語句将其呈現。
這個方式，就要求視圖中存在一定的邏輯語句，如将ViewData中資料轉換成相應類型的類型轉換語句；如果需要按照某一條件呈現不同内容，則需要分支語句；而常用的表格式資料呈現需要用到循環語句。于是，我們就會看到視圖中充斥着各種<%%>、if、foreach等等的東西。
2.對Ajax的支援：仍然很不友善
我們知道，現在在一個Web應用中加入Ajax元素是司空見慣的，微軟當然知道這一點，是以在ASP.NET MVC中，天然支援ASP.NET AJAX和jQuery，并提供了一個AjaxHelper來完成一些輔助性操作。然而，這個AjaxHelper的功能真是遠遠不夠。
由于ASP.NETMVC的特性，導緻某一個Action的Url不是固定的。是以在請求Action時，一般不是将Url寫死在頁面中，而是通過Html.ActionLink動态生成。這就出現了一個問題，Ajax請求怎麼辦？當然，對于點選連結或送出表單觸發的Action，AjaxHelper有專門的輔助方法，但是，如果某個Ajax請求不是通過連結或表單觸發的，就會很有問題。畢竟你不能把Url寫死在js裡。
總之來說，AspNet Mvc對比EFW MVC應該更靈活，适用的場景更多，而EFW架構雖然限制了一些功能，但是讓我們的學習成本與犯錯誤的機會更少，是以說EFW MVC更适合與行業軟體的開發，不太适合網際網路網站的開發；
大部分Web應用程式都是用像ASP，PHP，或者CFML這樣的過程化語言來建立的。它們将像資料庫查詢語句這樣的資料層代碼和像HTML這樣的表示層代碼混在一起。經驗比較豐富的開發者會将資料從表示層分離開來，但這通常不是很容易做到的，它需要精心的計劃和不斷的嘗試。MVC從根本上強制性的将它們分開。盡管構造MVC應用程式需要一些額外的工作，但是它給我們帶來的好處是無庸質疑的。
因為模型是自包含的，并且與控制器和視圖相分離，是以很容易改變你的應用程式的資料層和業務規則。如果你想把你的資料庫從MySQL移植到Oracle，或者改變你的基于RDBMS資料源到LDAP，隻需改變你的模型即可。一旦你正确的實作了模型，不管你的資料來自資料庫或是LDAP伺服器，視圖将會正确的顯示它們。由于運用MVC的應用程式的三個部件是互相對立，改變其中一個不會影響其它兩個，是以依據這種設計思想你能構造良好的松偶合的構件。
《AJAX的七宗罪》http://tech.163.com/05/1009/18/1VL1PAP300091589.html
罪之一：對搜尋引擎的支援不好
罪之二：編寫複雜、容易出錯
罪之三：備援代碼更多了
罪之四：破壞了Web的原有标準
罪之五：缺少一個沒有标準之争、沒有back和history的浏覽器
罪之六：XML隻是用來打幌子
罪之七：世界這麼大卻找不到自己的家
另外：講了這麼多，我們使用MVC的目的就是從根本上把界面和邏輯進行分離，但是我們也不要過度的剝離所有的關聯，因為這些剝離必然會讓你的代碼變得複雜，是以要有一個适當的平衡，而這個标準取決于業務功能複雜度。EFW架構中的MVC是經過了這麼一番磨練的，複雜業務功能實作有完全分離的方式，簡單業務功能實作有半分離方式；