后来我在工作中陆续使用过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进行开发的企业应该还是少数，因为现在已经有了更多、更好的选择。比如说Struts2、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说？您对今后的框架又有何想法呢？不妨一起探讨一下。