Struts2 的优点在哪里？

[onice]

本人初出毛庐，之前在学校的时候一直是用的 SSH 框架。请大家不啬赐教。

现在用过 SpringMVC 才知道 struts2 的臃肿。也明白为什么大家都说 SSH 很“重”。之前一直以为所谓的“重”是指的性能上的重。现在感觉更多的似乎是指使用的体验：

首先是配置上， Struts2 动不动都是一坨 XML 。不光是配置 action ，连做数据验证的时候都需要配置 XML 。不配置 XML 也可以，那就得在类里面单独写数据验证的方法。

其次就是在封装上。 Struts2 完全封装了 servlet ，如果不显示的去实现 RequestAware 这一套接口，使用的过程中感觉完全看不到 servlet 的影子，还自己搞了一个值栈。

还有就是 struts2 的拦截器机制。拦截器也是弄了一大坨，也搞成了拦截器栈。

action 类里面，如果不用 ModelDriven ，将会是一大坨 Getter 和 Setter 方法。

还听说 Struts 的官方处理漏洞，不是紧急修复，而是是直接把公布漏洞利用方法。。。

我感觉 Struts 的初衷似乎是想一个框架，通杀所有开发需求。尤其是 struts 的表单标签，我觉得一点都不好用。视图层完全交给前端技术不是更好么？

相比起 springMVC ， struts2 真的很难用。

这让我想起以前我问老师：像同轴电缆这种网络传输介质几乎已经没人用了。并且跟双绞线和光纤相比，根本不在一个档次，为什么还要花时间去讲它？老师却说：存在即为合理。

我觉得看待一项技术，不应该以现在的目光去看待它。而是应该结合当时的时代背景。

虽然现在我觉得 SpringMVC 的设计理念很先进，但我觉得未来肯定会有比 SpringMVC 更优秀的 Controller 框架，那个时候的人们也许会和我一样问： SpringMVC 那么难用，为什么当时还有那么多人用？

在没有 Spring 和 Struts2 的时候，那个时候的开发是怎样的呢？ Struts2 诞生后，又为开发解决了哪些问题，带来了哪些好处呢？ Spring 诞生后，又是哪些原因导致 struts2 没落了呢？

欢迎大家来讨论。

[acoder2013]

深呼吸

[murmur]

没啥优点了 唯一的优点就是老系统在用 然后他还在更 后端系统不是说换就换 何况承载的很多都是企业应用

[jukka]

去学个 python ，写写 flask ，然后再来比较可能体会就比较深了。:)

[ob]

要用发展的眼光看问题嘛，没有什么框架是会一步到位的，假如一开始没有 struts1 ， 2 的铺垫，也许就不会有 springmvc ， springmvc 的设计理念很多都是借鉴 struts 的嘛。

[mind3x]

Struts2 出来都十几年了，有什么好讨论的...难道国内有这么多 legacy 系统要维护？

[haozibi]

你们老师的存在即合理真的好没水准呀

[zhenizhui]

我也想过这个问题。

我还想知道，前端和 java 的配合，如果不是 SPA （还有 RESTFUL ），是不是写好静态页面给后台的人套？

[aias]

存在即合理 这句话是有误的…

[billlee]

同轴电缆要哭了，竟然被拿来和 structs2 比

同轴电缆可是能传递射频信号的，比双绞线不知道高到哪里去了。不用到以太网上是因为以太网使用的是基带信号，不需要这么好这么粗这么贵的传输介质。

[skydiver]

你们老师不懂康德

[johnj]

研究这些问题 纯属浪费时间 建议把有限的时间和精力用到更有用的地方

struts2 没有任何优势，除非是老项目，直接上 spring mvc 就可以了。

当然如果不用 spring 框架，那还得是用 struts2 。

[jinsongzhao]

感觉标准规范都很轻， servlet 3.0 几十行就能说明清楚就能用起来。包装是为了具体的开发需求，而需求会不断演变和流行淘汰，于是越包越重。几千上万行的说明，就包了个几十几百行的东西。

[nonesuccess]

@johnj 不用 spring ，但是用 springmvc ，可能还是比 struts2 强点。

我对 mvc 框架最大的怨念就是，看到前端一个请求，无法直接对应到后端的处理单元。先看 http url ，再找 xml ，再找 Java 类，烦都烦死了。不过我感觉这也就是一个 ide 插件能搞定的事

[abcbuzhiming]

楼主。你像个真正的程序猿了，不要被某些人误导说思考这些无意义浪费时间云云，其实一个真正的技术人员，绝对是会思考一个技术的来源的，因为只有懂得一个技术的来源，才会理解他的全貌，才可能窥见未来的一角。

“编程领域，任何技术被发明都是有需求的。没有莫名其妙被发明的技术”，这是我刚入行的时候就听到的一句话。我奉为经典。因此，从这个角度上讲，当你对任何编程领域的技术产生“它丫的为啥是这样的呢”的疑问时，你可以回去翻它的历史，细节的魔鬼就藏在历史里。
我们来谈谈历史，就你提到的 SSH 很重这个问题。首先要知道 SSH 在什么背景下逐步诞生，在 SSH 诞生之前， javaEE 的企业级实现是些啥玩意？是 weblogic ， JPA ， EJB 这些现在除了你可能在 IBM 这种大公司才看得到的庞然大物级的实现。嗯，可能我还漏了几个，不过无关紧要，这一整套玩意被奉为“企业级商业事务实现经典”（其实还有些细节我至今没弄明白，比如为啥企业级实现说来说去其实就是包装在 HTTP 上的 Web 应用，现在看起来很普通的东西为啥那个时候捧那么高）。这套东西及其庞大，可以涵盖当时企业商务应用，中间件等等一切领域。那个时候开源界没现在这么牛逼，剩下的实现只剩下 asp 和 php ，当年的这两货是不折不扣的玩具，没人正眼看的，而写 java server ，你写 jsp 那叫不专业。。。

你现在看 ssh 很重，你回头去看看上面写的那货就明白了，简直是木星和太阳的区别。。。

黑暗中总是会出现勇士的，第一个勇士就是 spring 的作者，他第一个跳了出来，写了篇文章对当时的 sun 公司这套实现大批特批（这文章我是在 iteye 还叫 javaeye 的时候在那看见的，现在还不知道有没有）。尤其大批了一通 JPA ，称它累赘的好似一坨翔。批判后不久 spring 就诞生了， spring 是简化后的实现，随后 sun 捐助给 apache 的 tomcat 给了 java 开源界很大的动力，因为它有限度的实现了 javaee 标准，又不像 weblogic 那么累赘，在此刺激之下，全世界第一个该领域的 MVC 框架 Structs 诞生（ MVC 模式的历史非常早，至少在 1960 年前后就有理论支持。很多人不喜欢这模式，但是这目前人类发明的最清晰的实现了）。随后慢慢的 SSH 才到了现在这样。

所以， Struts2 有什么优点呢？它没有，优点在 structs1 身上， 2 生不逢时，落后于时代了

SSH 你现在看起来重，是因为随着硬件发生和 Web 服务器技术的扩散，尤其是脚本语言的第一次崛起，引发了轻量化开发的狂潮， SSH 才显得笨重了。也激发了第二次瘦身， springmvc 甚至更轻的 Spring Boot ，数据库技术的稳定（关系数据库有一段时间彼此是半斤八两，使得以前要切换数据库的需求变成了伪命题）易用化导致 batis 这种更接近 SQL 的库开始大行其道。

至于未来会咋样呢，目前处在历史的岔道口，没有更好的方案。脚本语言在诞生时做错了一些事情：现在看完全去掉类型限定符对组织大项目是不利的，这也是为啥 2000 年后诞生的语言基本都是编译型语言，且有较严格的类型修饰符的原因。 PHP ， python 这类灵活的语言在前期的快速开发会陷入后期维护的陷阱， C++， C#， java 这类传统的强类型语言在添加了脚本语言的一些特性，如函数绑定，运行时类型判断后开发效率也追上来了。现在双方都在融合对方优点，试图在快速开发 /可维护性，轻量级框架 /更严谨的模型描述(分层)，之间找平衡。所以别看前端技术领域在纠结用啥好，后端其实也挺纠结用啥好的问题。后端比起前端来，可能唯一的优势就是因为历史够久，大部分流行技术都有委员会长期维护，不会像前端一样要考虑“这逼框架是不是过年了就没人维护了”这个坑爹问题(笑)

[q397064399]

楼上基本说完了，早些年 拍黄片跟 asp 是根本上不了台面的
J2EE 整套标准太重，光是 servlet 规范 就得好多页
实际上 spring 也是 J2EE 规范下的产物，毕竟还是运行在 servlet 上