二十7、EFW框架BS系統開發中的MVC模式探討

 回《【開源】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的七宗罪

 

1.MVC介紹

MVC 是一種使用 MVC（Model View Controller 模型-視圖-控制器）設計建立 Web 應用程序的模式:

　　Model（模型）是應用程序中用於處理應用程序數據邏輯的部分。一般模型對象負責在數據庫中存取數據。

　　View（視圖）是應用程序中處理數據顯示的部分。一般視圖是依據模型數據建立的。

　　Controller（控制器）是應用程序中處理用戶交互的部分。一般控制器負責從視圖讀取數據，控制用戶輸入，並向模型發送數據。

　　MVC分層有助於管理複雜的應用程序，由於您能夠在一個時間內專門關注一個方面。例如，您能夠在不依賴業務邏輯的狀況下專一於視圖設計。同時也讓應用程序的測試更加容易。

　　MVC 分層同時也簡化了分組開發。不一樣的開發人員可同時開發視圖、控制器邏輯和業務邏輯。

 

 

在EFW框架中：

Model：表明的就是ObjectModel、Dao和Entity

View：表明的就是JqueryEasyUI

Controller：表明的就是WebController

 

      有不少程序員每每把框架模式和設計模式混淆，認爲MVC是一種設計模式。實際上它們徹底是不一樣的概念。框架、設計模式這兩個概念總容易被混淆，其實它們之間仍是有區別的。框架一般是代碼重用，而設計模式是設計重用，架構則介於二者之間，部分代碼重用，部分設計重用，有時分析也可重用。

 

2.對比EFW MVC與Asp.Net 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更適合與行業軟件的開發，不太適合互聯網網站的開發；

 

3.爲何要使用 MVC

      大部分Web應用程序都是用像ASP，PHP，或者CFML這樣的過程化語言來建立的。它們將像數據庫查詢語句這樣的數據層代碼和像HTML這樣的表示層代碼混在一塊兒。經驗比較豐富的開發者會將數據從表示層分離開來，但這一般不是很容易作到的，它須要精心的計劃和不斷的嘗試。MVC從根本上強制性的將它們分開。儘管構造MVC應用程序須要一些額外的工做，可是它給咱們帶來的好處是無庸質疑的。

      由於模型是自包含的，而且與控制器和視圖相分離，因此很容易改變你的應用程序的數據層和業務規則。若是你想把你的數據庫從MySQL移植到Oracle，或者改變你的基於RDBMS數據源到LDAP，只需改變你的模型便可。一旦你正確的實現了模型，無論你的數據來自數據庫或是LDAP服務器，視圖將會正確的顯示它們。因爲運用MVC的應用程序的三個部件是相互對立，改變其中一個不會影響其它兩個，因此依據這種設計思想你能構造良好的鬆偶合的構件。

 

4.AJAX的七宗罪

《AJAX的七宗罪》http://tech.163.com/05/1009/18/1VL1PAP300091589.html

罪之一：對搜索引擎的支持很差

罪之二：編寫複雜、容易出錯

罪之三：冗餘代碼更多了

罪之四：破壞了Web的原有標準

罪之五：缺乏一個沒有標準之爭、沒有back和history的瀏覽器

罪之六：XML只是用來打幌子

罪之七：世界這麼大卻找不到本身的家 

 

另外：講了這麼多，咱們使用MVC的目的就是從根本上把界面和邏輯進行分離，可是咱們也不要過分的剝離全部的關聯，由於這些剝離必然會讓你的代碼變得複雜，因此要有一個適當的平衡，而這個標準取決於業務功能複雜度。EFW框架中的MVC是通過了這麼一番磨練的，複雜業務功能實現有徹底分離的方式，簡單業務功能實現有半分離方式；