今天，用一天時間研究了一下Spring MVC，spring-reference1.2.3關(guān)于MVC的那章周末的時候差不多看了一遍，并不是很仔細。不過也差不多了解了Spring-MVC是啥子玩意咯。
其實Spring MVC與Tapestry有“異曲同工”之妙。
先說“同工”，Tapestry最本質(zhì)的特點是什么？我認為頁面表現(xiàn)與java邏輯徹底相分離。而spring MVC也是相同的特點，它將頁面的java邏輯從頁面表現(xiàn)從抽取出來。Tapestry和Spring MVC在這個“分離原則”上，具有相同的理念。。。那么它們的“異曲”又是什么呢？
Tapestry將整個頁面表現(xiàn)及邏輯全部納入其框架，所以，它的頁面表現(xiàn)必須要求為html后綴，實際上，雖然我們最開始編輯的是一個單一的幾乎絕對純潔的HTML，但是在運行時，這個純潔的HTML通過Tapestry被過濾了一遍。過濾的目的是為了給每個組件生成唯一的HTML標簽的id以及展現(xiàn)組件功能。由于整個HTML都在Tapestry框架之中，所以對任何組件的操作，都可以在組件對象池里根據(jù)唯一的id獲取其實例。而每一個涉及到URL的組件都有其對應(yīng)的service，因此對組件“特定”的URL解析也是“特定”的。
再來看看Spring MVC，它如何將java邏輯與頁面表現(xiàn)分離呢？答案在其DispatcherServlet中。Spring MVC通過最傳統(tǒng)的在web.xml中過濾url方式，然后在[servlet-name]-servlet.xml配置文件中去匹配。一旦發(fā)現(xiàn)匹配的url，就觸發(fā)配置文件中對應(yīng)的java類。用配置文件來控制，是Spring一貫的特點。因此，Spring MVC的頁面表現(xiàn)，不拘泥于任何文件類型，java，htm，html等等，它所關(guān)心的僅僅是URL，甚至可以用鏈接標簽跳轉(zhuǎn)到一個根本不存在頁面，比如：http://localhost/test，只要[servlet-name]-servlet.xml中能夠匹配到這個URL中的/test，那么就不會報500錯誤，即進入了Spring MVC框架。至于從java邏輯到頁面表現(xiàn)的數(shù)據(jù)返回，Spring MVC用的是spring.tld標簽庫。
這種“異曲”造成了Spring MVC和Tapestry完全不同的思維理念，即Spring MVC仍然是面向標簽，而Tapestry則面向組件。
呵呵，所以我今天發(fā)現(xiàn)一個很有趣的現(xiàn)象。如果在JSP中使用Spring MVC，那么Spring MVC框架會發(fā)生作用，而JSP本身也會有JSP的Servlet。我想不出怎樣才可以將兩種Sevlet進行交互，在Spring官方論壇一定有人提供了解決辦法。。。呵呵，不過最后我發(fā)現(xiàn)這是個很愚蠢的想法，既然是使用Spring MVC將JSP中java邏輯分離出來，那么又何必在JSP中再用Java？如果要在JSP中用Java，又何必畫足添舌用Spring MVC？呵呵。。。
Spring MVC的確是簡單易學。周末嘛，玩游戲的時間居多，算下來看spring MVC也就兩三個小時，今天算一天，那么從接觸到應(yīng)用，我覺得三天時間差不多能夠搞定。在這點上，的確比Tapestry擁有很大的優(yōu)勢。我在javaeye上看見有人說，用Spring MVC（及開發(fā)工具）開發(fā)項目非?？?。我想，如果有工具能夠操作[servlet-name]-servlet.xml配置文件的話，的確應(yīng)該比較快。當然，這還牽扯到開發(fā)人員的熟練度。。。另外，我還看不出Spring MVC有任何復(fù)用的可能性。而且[servlet-name]-servlet.xml中寫入很多配置的話，還是比較混亂。就如同我們現(xiàn)在項目中的applicationContext.xml，當然并不是非?；靵y得很難識別，不過還是無法一眼看出各種URL與對應(yīng)類之間的各種配置關(guān)系。
Spring MVC 值得稱贊的另外一個優(yōu)勢，就是其單元測試非常容易。因為Spring的頁面邏輯類不像Tapestry，Tapestry的java文件全部是抽象類，自然無法作單元測試。
我之所以研究Spring MVC，實際上純屬“路過”。首要目的是為了了解Spring webflow。所以對Spring MVC的研究，差不多到此為止，了解一下即可。。。
