Struts2 的优点在哪里?

2016-10-29 17:51:56 +08:00
 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 没落了呢?

欢迎大家来讨论。

6054 次点击
所在节点    Java
15 条回复
acoder2013
2016-10-29 18:07:30 +08:00
深呼吸
murmur
2016-10-29 18:12:03 +08:00
没啥优点了 唯一的优点就是老系统在用 然后他还在更 后端系统不是说换就换 何况承载的很多都是企业应用
jukka
2016-10-29 18:22:20 +08:00
去学个 python ,写写 flask ,然后再来比较可能体会就比较深了。:)
ob
2016-10-29 18:51:15 +08:00
要用发展的眼光看问题嘛,没有什么框架是会一步到位的,假如一开始没有 struts1 , 2 的铺垫,也许就不会有 springmvc , springmvc 的设计理念很多都是借鉴 struts 的嘛。
mind3x
2016-10-29 19:42:53 +08:00
Struts2 出来都十几年了,有什么好讨论的...难道国内有这么多 legacy 系统要维护?
haozibi
2016-10-29 20:30:39 +08:00
你们老师的存在即合理真的好没水准呀
zhenizhui
2016-10-29 20:39:34 +08:00
我也想过这个问题。

我还想知道,前端和 java 的配合,如果不是 SPA (还有 RESTFUL ),是不是写好静态页面给后台的人套?
aias
2016-10-29 22:20:07 +08:00
存在即合理 这句话是有误的…
billlee
2016-10-29 23:31:57 +08:00
同轴电缆要哭了,竟然被拿来和 structs2 比

同轴电缆可是能传递射频信号的,比双绞线不知道高到哪里去了。不用到以太网上是因为以太网使用的是基带信号,不需要这么好这么粗这么贵的传输介质。
skydiver
2016-10-29 23:34:54 +08:00
你们老师不懂康德
johnj
2016-10-30 09:50:39 +08:00
研究这些问题 纯属浪费时间 建议把有限的时间和精力用到更有用的地方

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

当然如果不用 spring 框架,那还得是用 struts2 。
jinsongzhao
2016-10-30 12:58:56 +08:00
感觉标准规范都很轻, servlet 3.0 几十行就能说明清楚就能用起来。包装是为了具体的开发需求,而需求会不断演变和流行淘汰,于是越包越重。几千上万行的说明,就包了个几十几百行的东西。
nonesuccess
2016-10-30 17:30:17 +08:00
@johnj 不用 spring ,但是用 springmvc ,可能还是比 struts2 强点。

我对 mvc 框架最大的怨念就是,看到前端一个请求,无法直接对应到后端的处理单元。先看 http url ,再找 xml ,再找 Java 类,烦都烦死了。不过我感觉这也就是一个 ide 插件能搞定的事
abcbuzhiming
2016-11-04 22:00:20 +08:00
楼主。你像个真正的程序猿了,不要被某些人误导说思考这些无意义浪费时间云云,其实一个真正的技术人员,绝对是会思考一个技术的来源的,因为只有懂得一个技术的来源,才会理解他的全貌,才可能窥见未来的一角。

“编程领域,任何技术被发明都是有需求的。没有莫名其妙被发明的技术”,这是我刚入行的时候就听到的一句话。我奉为经典。因此,从这个角度上讲,当你对任何编程领域的技术产生“它丫的为啥是这样的呢”的疑问时,你可以回去翻它的历史,细节的魔鬼就藏在历史里。
我们来谈谈历史,就你提到的 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
2016-11-08 08:37:08 +08:00
楼上基本说完了,早些年 拍黄片跟 asp 是根本上不了台面的
J2EE 整套标准太重,光是 servlet 规范 就得好多页
实际上 spring 也是 J2EE 规范下的产物,毕竟还是运行在 servlet 上

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/316448

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX