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

MVC 1到MVC 2模型的進化

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

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

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

#p#

URL Mapping

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

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

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

<servlet>  
    <servlet-name>Example</servlet-name>  
    <servlet-class>com.xxx.xxx.Example</servlet-class>  
</servlet>  
<servlet-mapping>  
    <servlet-name>Example</servlet-name>  
    <url-pattern>/example</url-pattern>  
</servlet-mapping> 

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

<action name="example" class="com.xxx.xxx.ExampleAction">  
    <result name="success" type="dispatcher">/success.jsp</result>  
    <result name="input" ... />  
</action> 

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

對于不同參數(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進行訪問的時候，就自動mapping到這個example方法上：

/example/e1 

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

#p#

Data Binding

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

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

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

這當然不會入程序員的法眼了，于是框架替你把參數(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對象就自動被塞進這個Action去了。Spring MVC的情況類似，只不過粒度更小，參數(shù)注入的不是類Action實例的屬性，而是Controller方法的參數(shù)——當然，思想是一樣的。

#p#

視圖指向

你可能猜到我要說的內容了。程序員最原始的做法應該是類似這個樣子的：

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

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

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

如果找不到就找defaultHandler；

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

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

這種方式其實也是配置，但是既不是配置文件，也不是注解，更不是代碼，而是一個文件和文件夾的組織結構。

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

#p#

頁面聚合

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

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

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

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

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

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

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

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

<definition name="user" extends"main">  
    <put name="title" value="XXX Site - User" />  
    <put name="body" value="user.jsp" />  
    ... ...  
</definition> 

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

<decorator name="main" page="main.jsp">  
    <pattern>/*</pattern>  
</decorator>  
<excludes>  
    <pattern>/admin/*</pattern>  
</excludes> 

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

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

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

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

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

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