Struts 2.x仍然明顯落後於時代。 Struts 2.x這一類老牌Web MVC開發框架僅能用於開發瘦客戶端應用，沒法用來開發對於交互體驗要求更高的應用。

後來我在工做中陸續使用過Struts 1.x和Struts 2.x。我曾經把一個開源的基於Struts 1.x的自助式廣告聯盟應用移植到Spring MVC，還基於Struts 2.x作過網站開發。Struts 1.x的主要問題是框架的侵入性太大，不利於代碼重用和單元測試。Struts 2.x確實進步很大，徹底基於POJO，學習曲線低了不少，還支持零配置（不須要XML配置，甚至也不須要Annotation）。儘管如 此，Struts 2.x仍然明顯落後於時代。  Struts 2.x這一類老牌Web MVC開發框架僅能用於開發瘦客戶端應用，沒法用來開發對於交互體驗要求更高的應用。

2. Struts 1.x即將走完最後的歷程，對於那些仍在使用它的系統，你有什麼建議？若是要升級，有幾個備選方案，例如Struts 2.x、Spring MVC等等，你會如何選擇？

李錕：我建議選擇遷移到Spring MVC，我在這方面有一些實戰經驗。Spring MVC既支持Struts 1.x的開發方式（一個Action是一個Singleton對象，裏面有不少方法），也支持WebWork那種基於Command模式的開發方式（一個 Action是一個Prototype對象，只有一個方法）。從Struts 1.x移植到Spring MVC的難度不會很大，另外因爲Spring MVC仍然在持續發展，而且可以較好地支持REST開發，在我看來應該選擇哪一個框架是很明顯的。

張逸： 奇怪的是，雖然在早期我未曾有機會使用Struts 1.x，然而我如今正在工做的一個大型項目，由於其漫長的歷史，一部分Web前端使用的正好是Struts 1.x。對於這種正在使用它的系統，若要說有何建議，簡言之，仍是須要在決策時視狀況而定。在咱們當前項目的一個子系統中，Struts 1.x是與Spring MVC 2.0共存的；而在另外一個子系統中，又存在Struts 2.x與Spring MVC 3.x共存的狀況。從架構的一致性來看，這是很不合理的；然而就項目的真實狀況，我又認爲這種現象何嘗不可。遷移的成本每每是昂貴的，尤爲對於遺留系統而 言，若沒有覆蓋率極高的驗收測試，盲目地爲了追求架構一致性進行遷移，反而會引入新的問題。這就須要權衡遷移的成本和遷移獲得的好處。在Java平臺下， 可供選擇的成熟Web框架並很少，Struts 2.x以及Spring MVC相較於Struts 1.x而言，主要仍是體如今模式上的區別，屬於侵入性更小、架構更爲簡單的框架。相對於升級，我更傾向於保留原有框架，對於新增的功能則能夠引入更新的框 架。若由於種種緣由硬要升級，我更傾向於選擇Spring MVC，一方面它與Spring框架的集成度更好，學習曲線低；同時它對於Struts 1.x實現方式的固有支持，會使得遷移的成本會下降。最重要的一點是Spring MVC目前還保有必定程度的活力，它的版本還在演化中；相對而言，Struts彷佛已經失去活力了。

若拋開這些成熟的Web框架不談，個人建議是不妨試試Java平臺下的其餘框架，例如jRails，Spring Roo、Apach Wicket或者Play。若想繼續工做在Spring的技術棧下，Spring Roo會是一個有趣的選擇。事實上，你能夠認爲它是Spring所要力推的下一代Web框架，若是你不想重蹈Struts 1.x的覆轍，能夠在決策時冒着風險給予提早嚐鮮的機會。Play框架是基於Java和Scala開發的Web框架，它彷佛更偏重於建造可伸縮性的Web 框架。此外，它的安全模塊、持久化支持(包括對NoSQL與Big Data的支持)、RESTful以及Mobile的支持，使得它更適合開發當今的Web應用程序。

張龍： 前不久Apache宣佈Struts將EOL，其實我我的認爲這對於尚在使用Struts進行開發的項目來講不算是世界末日，畢竟Struts從第一個版 本到如今已經通過了不少年的發展，框架代碼也已經變得很是成熟，並且因爲開源，開發人員徹底能夠經過源代碼瞭解Struts的實現原理，並無什麼祕密可 言，並且Struts相關的文檔與資料也已經很是多了，因此我以爲並不會對現有項目形成太大影響。況且對於那些採用SAP進行二次開發的企業來講，因爲標 準代碼就是基於Struts框架的，所以採用Struts也是不二之選。從這個角度來講，我認爲Struts的EOL只是隨着軟件開發發展的一種正常現 象，畢竟十多年前的設計與架構如今已經沒法更好知足軟件開發之所需了，也算是軟件生命週期的一種必然結果。

若是是新的項目，我想選擇Struts進行開發的企業應該仍是少數，由於如今已經有了更多、更好的選擇。好比說Struts二、Spring MVC等。我對於這兩個框架都有必定的使用經驗，也開發過很多項目。我是個技術實用主義者，其實我我的認爲不管是Struts2仍是Spring MVC都是順應新時代的軟件開發潮流而產生的，在我我的看來，這兩個框架在設計哲學上存在較大的差別，但從實際項目開發的角度來講，不管哪個框架都是可 以勝任的。衆所周知，Struts2來源於Opensymphony（很遺憾，Opensymphony已經於一年前關閉了，其下的衆多項目也被獨立出去 單獨開發了）的WebWork，它與Struts沒有任何關係，只是藉助於當時很是流行的Struts這個名字而已，實質上仍是徹底沿用了WebWork 的設計思想與XWork這個微內核、基於命令模式的框架，另外在ValueStack和標籤庫上作了一些加強和改進。而Spring MVC則是一個後起之秀，而且在Spring的大旗下發展迅猛。從設計角度來講，Struts2採用了基於POJO的思想，摒棄了Struts的 FormBean，這樣每個Action都是一個有狀態的對象，所以須要針對每一個請求建立一個新的Action實例。另外因爲採用了OGNL，這使得 Struts2的標籤庫變得很是靈活和強大，又因爲Struts2的插件設計思想，咱們能夠很是輕鬆地採用已有的插件和開發本身的插件擴展Struts2 的功能，這使得Struts2的可擴展性變得很是強，目前Struts2的官網上已經有了幾十種常見插件供咱們使用，好比Spring集成、註解插件、 REST插件、與一些前端框架的集成等，對咱們的開發起到了很是大的幫助做用。

Spring MVC的設計思想與Struts2大相徑庭，它採起的策略有些相似於傳統的Servlet，即每個Controller都是無狀態的單例，客戶端參數的 傳遞是經過自定義方法參數獲得的，並且相對於Struts2的設計來講，Spring MVC的設計更加靈活，好比說咱們能夠自定義各類各樣的方法、能夠經過各類方式匹配客戶端的請求，而不像Struts2那樣只能經過URL來匹配，但這也 帶來一個問題，就是開發人員可能每一個人使用的方式都不同，爲項目的後期管理和維護帶來必定的問題。所以，在我所經歷的Spring MVC項目中，都會提早定義好各類規範和契約，使得你們遵循共同的訪問模式，這樣比較有利於項目的統一。

從我我的角度來講，我以爲選擇Struts2仍是Spring MVC仍是看項目組開發人員的技術掌握程度，或是想學一些新的技術這個方面的考量，畢竟兩者都很是成熟，並且都與Spring有着良好的集成。此外要提的 一點是，Spring MVC提倡基於註解的配置，Struts2默認使用XML（固然也能夠經過插件使用基於註解的配置），這個就要看項目組成員的想法了，有些人喜歡配置文 件，有些人喜歡註解，咱們不能說哪一個好哪一個很差，只是一種風格選擇而已。

3. 常常會有框架或軟件結束生命週期，再也不進行維護，這對使用它的用戶多多少少帶來了一些困擾 ，可否聊聊您在項目最初進行選擇時的一些經驗之談。

李錕：個人經驗是儘可能選擇一些基於POJO設計的開發框架，這樣代碼重用和單元測試都更容 易。另外儘可能選擇學習曲線低的開發框架，固然熟練掌握一種複雜的框架或者技術能夠做爲炫耀的資本，可是若是你處在一個團隊之中（而不是單打獨鬥），引入這 樣的框架極可能會極大增長團隊成員的負擔，從而極大增長開發和維護的成本。好的開發框架應該儘可能作到透明，應用程序運行於其中，程序員主要關注的應該是實 現應用自身的業務邏輯，而不是花不少精力與框架自己搏鬥。EJB 2.0問題很是多，因此如今已經沒人用了。進入成本和退出成本都很高的開發框架，哪怕再強大神奇，我也不會選擇的。KISS是一個很好的設計原則，也能夠 做爲開發框架的選擇原則。

張逸：對於框架的選擇，我比較偏重 於框架的簡單性和無侵入性這兩個特色。簡單性能夠保證咱們快速地理解框架的架構，並可以正確地使用它；無侵入性則使得咱們能夠避免所謂「供應商鎖定」的反 模式，在須要遷移框架時，能夠儘快擺脫原有框架的約束。固然，這種選擇總要結合項目需求，根據風險對各類質量屬性進行綜合權衡，方能作出合理的設計決策。 所以，我會將這兩個特色看作是重要的衡量指標，但並不是絕對。在必定程度上，咱們還能夠經過更好的架構設計來規避對框架的依賴，例如經過好的分層設計，或者 引入防腐層隔離對框架的依賴。以Struts 1.x而言，只要咱們避免在Action中引入業務邏輯，選用新Web框架的成本就會更低一些。同時，保證足夠的測試覆蓋率是必要的，尤爲是足夠覆蓋率的 單元測試與集成測試，它經常能夠放緩系統衰老的腳步。對於舊系統的維護或重構而言，測試覆蓋率是進行改造的良好基石。

張龍： 在項目技術選型時，我仍是比較激進的。老是但願在新的項目中讓你們能多學到一些東西、新的技術或是新的框架等，固然這是在保證項目按時交付的前提下須要考 量的因素。但有一點我是比較在乎的，那就是所選擇的技術是否已經有了一些成功的案例，資料文檔是否比較完備（咱們不能要求每一個人都仔細研讀所用開源項目的 源代碼），並且項目組中須要有人提早研究相應的框架，這樣在遇到問題時才能提出相應的解決方案。不管選擇什麼技術與框架，須要有人提早研究並給你們進行較 爲詳盡的介紹，同時還要與相關的技術框架進行一些橫向對比。至於軟件結束生命週期，不少時候是咱們沒法事先預料到的。但我想若是某個軟件結束生命週期，那 說明會有更多、更好用的軟件出現，這也會給咱們帶來更大的選擇，但要是對現有的軟件進行升級可不是一件容易的事情，好比將基於Struts的項目升級到 Struts2就是個極其艱鉅的任務，這時仍是要仔細權衡了，看看是否繼續沿用已有的框架，而後在新的項目中採用其餘方案，這並無統一的解決思路，仍是 要看實際的項目與業務狀況。

4. 隨着像Backbone.js這樣的前端MVC框架的流行，Struts這樣的服務器端MVC的做用彷佛有所減弱，您以爲MVC邏輯「前移」會是從此的發展趨勢麼？

李錕：MVC邏輯前移確定是從此的發展趨勢。其實在2005年Ajax和RIA技術興起時，Web MVC這種瘦客戶端應用的設計模式就已通過時了。

固然，Web應用的範圍極爲普遍。若是考慮到SEO，仍是有不少應用必需要作成瘦客戶端形式的，因此Web MVC開發框架仍然會存在不少年。可是對於移動應用來講，Web MVC確定已通過時了。注意這裏我說的是Web MVC，而不是MVC。在移動應用中，MVC做爲一種基礎設計模式，其實現已經徹底前移到客戶端，而服務器端則簡化爲單純的數據提供者，經過 RESTful Web Services爲客戶端提供數據。

張逸： 我徹底贊同這一點。在我參與的上一個項目中，對於服務端的Web層而言，幾乎就成爲了一個Controller+JSON+REST的組合，MVC中的M 被JSON或資源所替代，V則乾脆消失了，由Controller來負責必要的服務端驗證，並完成HTTP請求的路由功能，其他的前端邏輯都交由咱們當初 選擇的ExtJS了。

這種設計是徹底合理的。但我仍然要說明一點的是，這種設計因爲加大了前端的複雜度，於是須要咱們更加關注前端的代碼質量。傳統開發要求的關注點分離、鬆耦 合與高內聚原則一樣適用於這樣的前端代碼。雖然不必定要提倡前端代碼的測試驅動開發，但至少要保證這些代碼具備足夠的測試覆蓋率。例如，咱們能夠爲 Javascript（或者jQuery)引入Jasmine，QUnit等測試框架。在咱們曾經參與的一個項目中，由最初只支持一個品牌，加強到支持多 個品牌的需求變化，這其中須要涉及到對大量前端代碼的複用。因爲以前的設計並未考慮到多品牌的支持，於是須要重構前端代碼，以達成複用的目的。若是沒有足 夠的測試覆蓋率，以及良好的職責分離，要作到這一點的難度不言而喻。

張龍：Backbone 我在項目中使用過，其實我以爲前端MVC框架與Spring MVC這樣的後端MVC框架並不矛盾。他們嘗試解決的問題和麪向的對象是不一樣的，一個是如何實現前端的解耦，一個是如何實現後端的解耦，兩者確定會共存， 而且都有各自的用武之地。畢竟，前端MVC須要大量的JavaScript、CSS代碼，是否是每一個項目都須要作成這樣呢？相信每一個人心中都有本身的答 案。

此外，你們還就將來的開發框架作了些暢想，李錕對開發框架提出了一些要求：

• 繼續支持Web MVC模式仍然是基礎功能，至少不能比Struts 2.x、Ruby on Rails這樣的傳統開發框架作得差。
• 約定先於配置，對於大多數開發場景儘可能作到零配置。
• 模塊化、插件化、更好的可定製性，開發者能夠在覈心模塊的基礎上，根據本身須要添加不一樣的組件，而不是要麼全有、要麼全無。
• 低成本。更輕量級、學習曲線更低、性能更好、更容易配置和維護。
• 很好地支持REST開發，不只支持開發RESTful WebService，還支持開發RESTful WebApp。
• 集成並提供大量Web前端的開發控件，而且能與服務器端組件創建流暢的交互流程。

他認爲從此必會出現面向移動Web應用（富客戶端）開發的一站式框架，從Web前端一直到持久層徹底打通，把客戶端的MVC和服務器端的MVC結合在一塊兒，其中有5個組成部分，客戶端有MVC，服務器端再也不有V，只有MC。

目前客戶端MVC開發框架已經很是多了，不少支持MVC的JS框架，Flash也有Pure MVC等多種選擇。可是它們與服務器端的MVC開發框架並無作很深刻的整合，這樣又出現了當年Struts、Spring、Hibernate各自爲戰 的局面。初學者的入門門檻很高。2005年Ruby on Rails橫空出世以後，自覺得牛X的SSH當即風光再也不。你們恍然大悟，其實Web開發應該這樣作。複雜不是王道，簡化纔是王道。

張逸很是認同李錕提到的這個模式：

許多模式事實上都是從MVC模式衍生而來，例如MVP等。此時，MVC能夠做爲核心模式的一個名詞。應該爲那些變種的模式命名，並給出最佳實踐，從而表達特定的含義。

他建議將這種模式命名爲MC2MVC，或者RC2MVC。有個「2」，就表示從服務端到客戶端的意思。至於RC2MVC，則是爲了強調服務端提供的「資源」，而非傳統意義上的模型。

筆者也一樣很是認同這種模式，但在具體的框架實現上稍有不一樣：

我相信MVC前移這個必定是趨勢，並且JS的框架如今也愈來愈強大了，後端服務器上的MVC的V將漸漸地變爲REST接口，爲前端MVC提供數據。可是我 並不但願再出現一個相似Rails的一站式框架，從前端到後端通通囊括在內。Rails在剛誕生的時候的確引發了不小的轟動，可是時至今日，它的問題也是 很是的多，好比默認開啓了太多的功能，還有在非Web領域方面的應用問題，Robbin的那篇 《Ruby社區應該去Rails化了》已經寫的很是清楚了。我更但願能看到多個框架分別負責前端MVC，後端的MC，各自作精作好，而後再有一個粘合劑框架將先後串聯起來。你們都能獨立發展，能夠很方便地替換框架，固然，這也是要求能作到很高的非侵入性。

各位讀者，不知您是否也有一些話想對Struts 1.x說？您對從此的框架又有何想法呢？不妨一塊兒探討一下。