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说？您对从此的框架又有何想法呢？不妨一块儿探讨一下。