古风小说,千年殇,盗墓笔记同人小说

新聞中心

這里有您想知道的互聯(lián)網(wǎng)營銷解決方案

MVC框架的映射和解耦

最近在寫一個業(yè)務(wù)上用到的框架，回想起接觸過的一些MVC框架，尤其是主要貢獻(xiàn)在后端表現(xiàn)層上的那些，它們之間有太多的相似，在不斷解耦的過程中，層數(shù)和模塊數(shù)也越來越多，需要不斷引入層與層之間的映射邏輯將不同層次之間關(guān)聯(lián)起來，我們不妨來查看一下這個過程，能否尋找一些MVC框架的共性和啟示。

MVC 1到MVC 2模型的進(jìn)化

這個話題有點(diǎn)老。MVC 1在桌面程序中應(yīng)用較多，業(yè)務(wù)邏輯當(dāng)然放在Model里面，Controller負(fù)責(zé)將用戶的請求數(shù)據(jù)傳遞到Model去，之后就放手不管了，讓View通過觀察者模式不斷獲知Model的最新變化（可以是Model變化后通知View，也可以是View自己來獲?。＿@個模式看起來很簡單，不過很容易發(fā)現(xiàn)一個嚴(yán)重的問題，View必須對Model了如指掌，要不然怎么觀察它呢。這實(shí)在是一件不甚合理的事情。

MVC 2則解開了Model和View的耦合，Controller變成了中介者一樣的角色，View接收了用戶輸入，Controller把處理請求分派給Model，處理完后，又把結(jié)果交回View來展現(xiàn)。不過，這樣的代價是Controller變成了一個百事通，如果它要關(guān)心Model和View的具體實(shí)現(xiàn)，耦合的問題只是換了一件外衣而已。所以，需要對Controller進(jìn)一步解耦。下面的話題，也是借由這一點(diǎn)展開的。

從這個改變就可以看出在解耦方面的進(jìn)化，但是依然沒有做足，后來ASP.NET又出了MVC 3、MVC 4，我沒有去了解其中的變更。這只是關(guān)于解耦的一個前傳，下面讓我們回到正題，看看那些隨著解耦的進(jìn)一步進(jìn)行，新產(chǎn)生的映射邏輯和配置。

#p#

URL Mapping

也許最早會有人這樣寫代碼：

 
 
 
 
  
  
  
  if("/ServletTest/eg1".equals(request.getURI()))  
  
  
  
      xxx;  
  
  
  
  else if("/ServletTest/eg2".equals(request.getURI()))  
  
  
  
      xxx;  
  
  
  
  ... ...

但是現(xiàn)在應(yīng)該已經(jīng)不會有人這樣寫了，印象中即便是最早只是用JSP+Servlet寫程序的那一批程序員寫網(wǎng)站應(yīng)用的時候，URL和控制器入口的映射邏輯也已經(jīng)被獨(dú)立出來了，例如Tomcat的web.xml：

 
 
 
 
  
  
  
    
  
  
  
      Example  
  
  
  
      com.xxx.xxx.Example  
  
  
  
    
  
  
  
    
  
  
  
      Example  
  
  
  
      /example

但是這樣的配置匹配的表達(dá)式不夠靈活（例如無法自定義匹配邏輯），而且配置過于冗長（通常來說，我是一個xml配置文件的痛恨者），于是現(xiàn)今的MVC框架都提供了一套自己的映射匹配邏輯，例如Struts2：

 
 
 
 
  
  
  
    
  
  
  
      /success.jsp

還可以配置全局的跳轉(zhuǎn)邏輯，傳遞參數(shù)等等，總之配置是靈活多了，可是每寫一段控制器的邏輯，還是需要配置一段到XML文件中。這樣的問題也是可以解決的，將變化點(diǎn)獨(dú)立到Action里，配置文件中只寫這個變化的參數(shù)，這樣只需要一個配置就可以完成大部分跳轉(zhuǎn)了。

對于不同參數(shù)名稱和參數(shù)個數(shù)變化的情況，上面的辦法支持得又不好了，好在許多框架都提供了注解配置的辦法，把URL映射的邏輯變成短短的注解：

 
 
 
 
  
  
  
  @Results( { @Result(name = "success", location = "/success.jsp"), @Result(name = "error", location = "/error.jsp") })

可是這幫難伺候的程序員啊，還是嫌麻煩，這就需要利用CoC原則（規(guī)約優(yōu)于配置，Convention over Configuration）。在Spring MVC中，聲明了ControllerClassNameHandlerMapping以后，對于這樣沒有配置任何映射信息的方法：

 
 
 
 
  
  
  
  @Controller 
  
  
  
  public class ExampleController extends MultiActionController{  
  
  
  
     
  
  
  
      @RequestMapping 
  
  
  
      public void e1(...);  
  
  
  
  }

類名叫做ExampleController，方法名叫做e1，因此在使用如下URI進(jìn)行訪問的時候，就自動mapping到這個example方法上：

 
 
 
 
  
  
  
  /example/e1

好了，這總滿足懶惰的程序員你了吧。

#p#

Data Binding

這里Data Binding（數(shù)據(jù)綁定）指的是將用戶請求提交上來的數(shù)據(jù)和領(lǐng)域模型綁定起來，即生成若干個攜帶數(shù)據(jù)的模型對象。

自不必說，最原始的方式應(yīng)該是類似這樣的解決方法：

 
 
 
 
  
  
  
  User user = new User();  
  
  
  
  user.setName = (String)request.getParameter("name");  
  
  
  
  user.setAge = (Integer)request.getParameter("age");  
  
  
  
  ... ...

這當(dāng)然不會入程序員的法眼了，于是框架替你把參數(shù)綁定到一個數(shù)據(jù)集合的對象上，你獲取起來就容易多了，比如在Grails框架中，可以這樣寫：

 
 
 
 
  
  
  
  def example = {  
  
  
  
      def name = params.name;  
  
  
  
      def age = params.age;  
  
  
  
      ... ...  
  
  
  
  }

或者干脆換成參數(shù)映射的配置文件，可是還是好啰嗦，于是“規(guī)約優(yōu)于配置”又來了，以Struts2為例：

 
 
 
 
  
  
  
  class UserAction{  
  
  
  
      private User user;  
  
  
  
      //get/set方法  
  
  
  
  }

這種情況下，只要提交這樣的請求：

 
 
 
 
  
  
  
  /example/userAction?user.name=Jim&user.age=18

這個name為Jim、age為18的User對象就自動被塞進(jìn)這個Action去了。Spring MVC的情況類似，只不過粒度更小，參數(shù)注入的不是類Action實(shí)例的屬性，而是Controller方法的參數(shù)——當(dāng)然，思想是一樣的。

#p#

視圖指向

你可能猜到我要說的內(nèi)容了。程序員最原始的做法應(yīng)該是類似這個樣子的：

 
 
 
 
  
  
  
  request.getRequestDispatcher("/common/success.jsp").forward(request, response);

之后進(jìn)化成為配置文件配置的形式、注解配置的形式，有了前文的介紹，這實(shí)在是沒什么特別的。值得一提的是，我用過一個框架，它對于URL Mapping（front-controller做的事情）和View Routing（backend-controller做的事情）通過這樣一種有趣的機(jī)制來完成：

根據(jù)URL路徑和Controller返回的結(jié)果字符串去尋找相應(yīng)目錄下對應(yīng)名稱的handler；

如果找不到就找defaultHandler；

如果還是找不到就往上一級目錄去找，依此類推。

舉例來說，Controller返回View的路徑為“user/admin/do”，就到…/user/admin目錄下尋找一個do.handler的文件，找不到就尋找同目錄下的default.handler，再找不到就往父目錄去遞歸尋找。這種機(jī)制就使得URL Mapping和View Routing的過程變得具有天然的繼承性（比如公用的success.handler可以放在頂級目錄中）。

這種方式其實(shí)也是配置，但是既不是配置文件，也不是注解，更不是代碼，而是一個文件和文件夾的組織結(jié)構(gòu)。

最后，你肯定知道我還是要回到“規(guī)約優(yōu)于配置”上面來。效果就是，例如訪問user/do默認(rèn)完成后就去尋找…/user/success.jsp，異常后通過異常攔截器首先尋找…/user/failed.jsp。

#p#

頁面聚合

對于服務(wù)端頁面模板的組織在我看來一直是網(wǎng)站應(yīng)用編程中比較薄弱的一塊（客戶端頁面聚合即前端頁面聚合我在此先不討論），直到現(xiàn)在，頁面模板的代碼還是極容易陷入過于復(fù)雜和不易理解的境地。最開始追溯到JSP誕生以前的時代，頁面是可以由Servlet一行一行輸出的：

 
 
 
 
  
  
  
  PrintWriter pw = response.getWriter();  
  
  
  
  pw.write("xxx");  
  
  
  
  ... ...

那個時候還沒有頁面模板的概念。于是JSP出現(xiàn)，可以把頁面HTML和頁面上用于展示的Java代碼糅合在一起。至于JSP最初就容易被誤用做了更多的展示以外的事情，那其實(shí)并不是工具本身的錯。直到現(xiàn)在，還有許多人對于Servlet和JSP有相當(dāng)?shù)钠?，在程序員聊天的時候，你要是說你的網(wǎng)站是用Servlet+JSP做的，對方往往會直接鄙視你，用那么老土的技術(shù)。其實(shí)技術(shù)本身并沒有任何錯，Servlet+JSP依然可以非常漂亮地解決很多實(shí)際問題。

對于頁面模板，無論你是使用JSP，還是FreeMarker、Velocity，你都會面對一個問題，一個和Java代碼、C++代碼一樣需要依賴和組織的問題。于是程序員就將頁面分為幾個子頁面，通過這樣的方式引入：

 
 
 
 
  
  
  
  <%@ page import="xxx.jsp" %>

不過，對于一些公共的頁面而言，可能要被許多頁面引用，幾乎所有的結(jié)果頁面都要引入header.jsp、menu.jsp、footer.jsp……并傳遞一些類似的參數(shù)。這讓啰嗦的程序員又覺得不開心了，我應(yīng)該把我有限的精力專注到業(yè)務(wù)特有的邏輯和頁面上去，這些通用的部分框架能不能替我聚合，而我就不需要關(guān)心了？

這和異常處理很像，很多項目都喜歡定義自己的總異常，繼承自RuntimeException，不需要聲明，而且在通用異常攔截器內(nèi)統(tǒng)一處理這些未被捕獲的異常，完成通用的邏輯處理和頁面轉(zhuǎn)向；而錯誤信息就通過異常攜帶出來了，程序員就不需要把精力分散到大量的異常信息傳遞上面——比如通過返回碼這種需要單獨(dú)處理的形式，記得在老項目（特別是存儲過程）的業(yè)務(wù)邏輯中還經(jīng)?？吹藉e誤信息的返回碼，現(xiàn)在真是越來越少見了。

于是Tiles給了這樣的頁面聚合辦法，配置文件：

并且可以靈活地使用繼承和參數(shù)傳遞，可是依舊不爽，每一個頁面跳轉(zhuǎn)都要配置這樣一塊豆腐干，實(shí)在是很啰嗦。SiteMesh提供了一種更為簡潔的配置方式：

這樣一來，所有的請求（除了匹配“/admin/*”這樣的）全部都走到基于main.jsp聚合的邏輯中去了，通用的部分全部在main.jsp中完成，變化的頁面依然根據(jù)原有的View Routing的映射來尋找頁面，聚合這件事情，就真正對后續(xù)開發(fā)的程序員透明了。

對于框架來說，還有進(jìn)一步解耦的需求嗎？有。比如可配置的攔截器，對于不同的請求能夠使用配置為不同數(shù)量和不同個數(shù)攔截器的“攔截器棧”來響應(yīng)，既可能有前置處理，也可能有后置處理。攔截器把原本在許多業(yè)務(wù)里都要重復(fù)做的事情（比如權(quán)限校驗）通過AOP這種形式橫向切一刀給做了。再比如序列化，如果要返回頁面，形式可能是text/html的，而要傳遞對象，形式可能就是application/json這樣的，將頁面或者對象轉(zhuǎn)換成html或者JSON響應(yīng)的活兒，程序員當(dāng)然也不想干……

縱觀上面介紹的這些MVC框架在解耦和映射方面做的貢獻(xiàn)，我們很容易看到，在不斷地解耦過程中，層數(shù)、模塊數(shù)不斷在增加，復(fù)雜性應(yīng)該說也在增加，配置當(dāng)然更復(fù)雜，可是愛偷懶的程序總有辦法讓復(fù)雜變得簡單。這個因解耦引起層與層之間映射的配置便是如此：

程序員自己實(shí)現(xiàn)；框架實(shí)現(xiàn)，但是需要手動配置；規(guī)約優(yōu)于配置。

正是程序員對于懶惰的追求，造就了一個又一個好用的MVC框架，現(xiàn)在開發(fā)一個網(wǎng)站對于十多年前來說，實(shí)在是簡便太多太多了，在今天談?wù)摰慕嵌壬希磥鞰VC框架還會有怎樣的發(fā)展趨勢呢？還有哪一些通用的部分會被解耦出來，你又怎么看？

原文鏈接：http://www.raychase.net/850

當(dāng)前題目：MVC框架的映射和解耦
本文網(wǎng)址：http://fisionsoft.com.cn/article/dheeohc.html

新聞中心

其他資訊