我为什么不用struts

在我眼里，struts还有几个关键的缺点，所以我用了3-5个项目后就不用了。

主要的缺点有这么些：

1、输入输出变量范围定义不清晰。在一个action中，所有输入输出变量都是作为对象变量存在的，既无法区分某个变量是属于哪个方法的，也不能区分哪个变量是输入变量还是输出变量。有人说，我每个请求都用单独的action来处理不就行了。这个办法的确可以区分每个请求之间的输入输出，但是你会面临action数量急剧膨胀的问题。

     输入输出变量定义不清晰的带来的问题是代码可读性比较差。使用struts的时候，极端情况下，你得把jsp+action+js结合起来看才能确定某个请求有哪些输入输出。这对项目的维护者来说实在是件很痛苦的事情。

 

2、struts在处理ajax请求的时候太不方便了，虽然你可以配置一个插件让strus具备返回json result的功能。但是目前的插件距离我的实际需要还是有差距的。主要的问题在于，struts现有的json插件不能定义java对象序列化到json对象时的映射策略。就拿User对象来说吧，假如我目前设计的是订单界面，订单又引用了User对象作为订单的制单人属性。那么在序列化Order对象到前端的时候，我只需要序列化User对象的id,name就够了，user对象的其他属性可以统统不要。但我如果在维护用户的模块中，显示用户列表的时候，通常要显示用户对象的大部分属性。因此java对象到json对象的序列化策略应该是运行时动态设定的，不可能用annotation来申明。但struts以及struts插件并没有提供运行时根据请求为某个类选择不同映射策略的功能。

 

struts2，学习成本不可谓不高，功能不可谓不强大，但不符合我的需求。

 

学习strus2，假如不花个把月时间静下心来学习和实践，估计没人敢说自己精通strus2了。但mvc真的有必要那么复杂么？

 

mvc是什么？他应该能干什么？他的核心价值在哪？最小的mvc应该包含哪些功能？我们自己写一个mvc如何？自己写一个mvc框架需要超过一个月时间么？

评论

98 楼 ily 2011-04-19  

george 写道

你说的两个问题，可以归纳为：
1：Struts2 的Action是有状态的，存在成员变量；
2：Struts2 不能很好地支持json/xml甚至jpg等格式的输出；


你这两个问题，可以使用Spring MVC 3 来解决，但是如果使用Spring MVC 3，又引入一个致命的问题：Spring MVC 3 使用annotation可以把藏在任意层次的类映射到一个url上，这样，如果项目管理人员无法强制约束组员的命名风格和包路径存放规范，会造成到看到一个url，到处去找其对应的控制器类的问题。
使用struts2-convention-plugin 就不会有这个问题，因为它是使用约定的，你不按照约定来存放和命名action，你的url根本就无法访问，程序也运行不起来。

另外，Struts2所使用的模型驱动还有一个问题：当你的页面输入框内输入的数据类型，和实体类定义的数据类型不一致时（比如实体类A字段类型为Integer，而页面上为该字段输入了aaa），提交页面，Struts2既不报错，也不能执行，程序根本就不会进入Struts2的方法（使用struts2-convention-plugin 时），这是一个大问题。

但是和Spring MVC 3 的包路径无约束造成的项目混乱相比，Struts2的种种缺点我还是忍受了。

所以综合上述，我还是选择了Struts2

    说得很好。struts两年，SpringMVC1年，现在用的是SpringMVC，至于杂乱嘛，人为规范管理好命名路径就可以。相比来说，Struts就很规范，但也存有不足，主要看你项目要求和你个人习惯而定。

97 楼 ctoeye 2011-04-19  

完事，收工！

96 楼 ctoeye 2011-04-19  

ice123456 写道

hexiaodong 写道

ice123456 写道

说句实话。我承认你说的都比较在理，有时候自己写一个简易工具（个人认为只是工具而已），有时候可能认为会比框架的功能好，也可以避免很多效率的问题。  但是我感觉你上面说的话，有点过重，导致其他喜欢struts2的人有点反感而已。

简单就是最好的设计，现在讲点道理，顾虑可真多啊。

同意。就跟写代码一样，不用注释的代码就是最好的代码。但是你也认为你和你的同事或下属都是一样或差不多的水平吗？  你认为你永远不会带入学生开发人员吗？  我相信学生也可以很快去学习你写的框架，但是不一定他能理解你所完成的功能。

为什么要理解所完成的功能，会用就行。底层的开发，本来就是码农。

95 楼 ctoeye 2011-04-19  

hexiaodong 写道

我的同事或者下属不一定要和我差不多水平，他们不学我的框架开发，就只能学更复杂的struts1或者struts2了。
我的框架仅需要1-2个小时的学习成本而已，前端都是封装好的Js控件，一般都是需要编写的js代码主要有form.getValue(),grid.getValue()和tree.getValue()等等，然后把得到的结果提交到服务器段就行了。

要说快速开发，你没见过从底层hibernate底层表结构到复杂界面拖拖拉拉生成的RAD框架吧？

94 楼 ctoeye 2011-04-19  

hexiaodong 写道

我要说的就是struts又复杂，又不能满足现在的需求啊。
再说了,order.user.id之类的命名又不是什么http规范，仅仅是struts为了能够把http参数注入action而约定的input命名格式。
采用json格式提交数据，既能够使代码最简化，又能提供最大的灵活性。

就struts那点破东西，你都觉得复杂，我就没什么话说了。json是一种好东西。

93 楼 ctoeye 2011-04-19  

hexiaodong 写道

ice123456 写道

说句实话。我承认你说的都比较在理，有时候自己写一个简易工具（个人认为只是工具而已），有时候可能认为会比框架的功能好，也可以避免很多效率的问题。  但是我感觉你上面说的话，有点过重，导致其他喜欢struts2的人有点反感而已。

简单就是最好的设计，现在讲点道理，顾虑可真多啊。

什么叫简单就是最好的设计？简单是要看场景的。一个大型的项目，不是简单那么简单。要考虑很多的东西，通用性、标准化、可扩展、易维护等等。讲道理可以，不过不要做井底娃，不要老抱着手里那点小成就不放。比你牛的人多了去了，写的框架也比你复杂多了。

92 楼 ctoeye 2011-04-19  

ice123456 写道

麻烦几位，技术出身就只牵扯技术就算了。  没什么好咬人不咬人的

你会咬人呀？

91 楼 ctoeye 2011-04-19  

hexiaodong 写道

ctoeye 写道

。。。。
复杂的对象组合，是在service层完成。action本身就不应该做这些东西。你在action做这些封装本身就是你设计的失误！action只是简单的中转。也就是说你这个order直接放在action的属性中，或者可以定义model驱动。界面直接order.xx.xx就完事了。多麻烦的事？
还json,还map，不知道你要搞什么？你搞的那点东西就你自已懂，别人怎么办？以后的人怎么办？struts是大家都懂的，后来的人学习成本低。也利于产品的维护。不懂就学,别jjyy。
我以前公司有个人拿他写的所谓的mvc框架给我看，说多么多么好，被我一陈批。不知道这个人是不是你。

order.details是一个集合，而不是一个简单属性。你能用order.details.goods.id的方式让order对象关联到一个集合，而集合中又包含一些goods对象么？
复杂对象的组装如果都在service层完成，那么在用户在做一件事情的时候，你不得不让用户的浏览器和服务器进行很多次的交互。当然你可能没有见过复杂的交互，这不奇怪的。但是最好别乱咬人。

为什么不行？
在做一件事情的时候，什么多次交互？没有ajax的吗？根本不知道你说的什么。你那破web应用有什么复杂的交互，我就奇了怪了。搞游戏的界面比你的交互复杂吧。界面的复杂度和用不用什么框架根本就没什么关系。是你咬人吧。

90 楼 ice123456 2011-04-19  

差点睡了...结果看到这个比喻笑醒了

89 楼 Agrael 2011-04-18  

simon_zhm 写道

Agrael 写道

simon_zhm 写道

楼主到底有没有真正玩过jsonplugin啊，你第二个问题说的是问题么，jsonplugin的配置不是可以让你用正则来设置哪些属性返回，哪些可以不要么，再说了什么输入型参数，输出型参数，要关注这些干嘛呢，就因为这些微不足道的东西把struts批得这么不是，学习成本高？再高也没有自己重写一个高吧，模仿一个MVC框架的功能并不难，难的是你这么短的时间内，能写出具有通用性，扩展性的框架么

这里也能见到你-。-无处不在啊。
是啊，想想学习成本。。。。。我写的框架MVC部分的xml配置和注解配置都尽量向struts2靠拢，都是尽量减少学习成本。。。。。。

是啊，没事就上来逛逛，突然看到这个标题，忍不住进来，举的这两个问题，看得我心发毛啊，这些都是问题么，感觉就是个标题党

就好像买了一台骄车不会开，然后大叫，老板，你这车有问题...这么复杂，你看自行车多方便啊，两脚一蹬就能跑了

认识你到现在，见过你做的最牛的一个比喻。。。。。

88 楼 peterwei 2011-04-18  

simon_zhm 写道

Agrael 写道

simon_zhm 写道

楼主到底有没有真正玩过jsonplugin啊，你第二个问题说的是问题么，jsonplugin的配置不是可以让你用正则来设置哪些属性返回，哪些可以不要么，再说了什么输入型参数，输出型参数，要关注这些干嘛呢，就因为这些微不足道的东西把struts批得这么不是，学习成本高？再高也没有自己重写一个高吧，模仿一个MVC框架的功能并不难，难的是你这么短的时间内，能写出具有通用性，扩展性的框架么

这里也能见到你-。-无处不在啊。
是啊，想想学习成本。。。。。我写的框架MVC部分的xml配置和注解配置都尽量向struts2靠拢，都是尽量减少学习成本。。。。。。

是啊，没事就上来逛逛，突然看到这个标题，忍不住进来，举的这两个问题，看得我心发毛啊，这些都是问题么，感觉就是个标题党

就好像买了一台骄车不会开，然后大叫，老板，你这车有问题...这么复杂，你看自行车多方便啊，两脚一蹬就能跑了

你这个比喻太搞了。

87 楼 hexiaodong 2011-04-18  

正常情况下，客户端会做第一次验证的。所以用户正常通过浏览器界面提交的数据在服务器端验证一般都是能通过的。

极少数情况会在服务器端验证失败，所以你说的性能浪费，我认为可以忽略不计。

86 楼 simon_zhm 2011-04-18  

Agrael 写道

simon_zhm 写道

楼主到底有没有真正玩过jsonplugin啊，你第二个问题说的是问题么，jsonplugin的配置不是可以让你用正则来设置哪些属性返回，哪些可以不要么，再说了什么输入型参数，输出型参数，要关注这些干嘛呢，就因为这些微不足道的东西把struts批得这么不是，学习成本高？再高也没有自己重写一个高吧，模仿一个MVC框架的功能并不难，难的是你这么短的时间内，能写出具有通用性，扩展性的框架么

这里也能见到你-。-无处不在啊。
是啊，想想学习成本。。。。。我写的框架MVC部分的xml配置和注解配置都尽量向struts2靠拢，都是尽量减少学习成本。。。。。。

是啊，没事就上来逛逛，突然看到这个标题，忍不住进来，举的这两个问题，看得我心发毛啊，这些都是问题么，感觉就是个标题党

就好像买了一台骄车不会开，然后大叫，老板，你这车有问题...这么复杂，你看自行车多方便啊，两脚一蹬就能跑了

85 楼 peterwei 2011-04-18  

hexiaodong 写道

我的同事或者下属不一定要和我差不多水平，他们不学我的框架开发，就只能学更复杂的struts1或者struts2了。
我的框架仅需要1-2个小时的学习成本而已，前端都是封装好的Js控件，一般都是需要编写的js代码主要有form.getValue(),grid.getValue()和tree.getValue()等等，然后把得到的结果提交到服务器段就行了。

如果你做过很多开发，你不会说这种话。web应用，最花工作量的地方在于界面的编写调试和js写各种效果。至于mvc框架，不管是webwork,struts2,springmvc,自已写的，都是浅浅的一层，几乎不会花时间的。

84 楼 Agrael 2011-04-18  

hexiaodong 写道

Agrael 写道

simon_zhm 写道

楼主到底有没有真正玩过jsonplugin啊，你第二个问题说的是问题么，jsonplugin的配置不是可以让你用正则来设置哪些属性返回，哪些可以不要么，再说了什么输入型参数，输出型参数，要关注这些干嘛呢，就因为这些微不足道的东西把struts批得这么不是，学习成本高？再高也没有自己重写一个高吧，模仿一个MVC框架的功能并不难，难的是你这么短的时间内，能写出具有通用性，扩展性的框架么

这里也能见到你-。-无处不在啊。
是啊，想想学习成本。。。。。我写的框架MVC部分的xml配置和注解配置都尽量向struts2靠拢，都是尽量减少学习成本。。。。。。

呵呵，你也是自己写mvc框架的啊。

在我写mvc框架的时候，webwork没有那么多插件，功能比现在的还弱，使用范围也没有这么广。所以很多年前就是自己写的了，也没想过向struts靠拢。

我觉得mvc本身没那么复杂，如果你不向struts靠拢，团队成员学习成本也许更低。就像我的框架，出了java-json映射策略需要配置，其他配置几乎等于0。学习成本1-2节课的时间而已。

只是配置的形式靠拢，并不是所有的设计啦。

验证可以使用注解或者其他的配置形式来配置。当然写java代码也可以。
2者都可以重用，不过用注解或者其他配置的形式的可读性比较高，也可以更好的文档化。
形式上：
只是一种是 获取参数--》类型转换--》验证--》构造对象
另外一种是 获取参数--》转换--》构造对象--》验证
看似很类似，不过如果中间有验证失败的，那么第二种的构造过程就是多余的，浪费性能。

83 楼 hexiaodong 2011-04-18  

peterwei 写道

有什么好吵的。我们现在都用flex搞富客户端。你说的各种js控件，各种取值，各种复杂企业界面，我从webwork开始到struts2到springmvc,在各种企业应用+web网站都用得好好的。这些框架都能实现复杂界面和取值，没什么实现不了的。能不能实现在于人。你说你写了那么个框架，自已用就是了。毕竟struts2,springmvc是大流，也很好用。

我的题目是我自己为什么不用，没有说你们都不要用啊。

82 楼 peterwei 2011-04-18  

hexiaodong 写道

在用户对操作体验要求越来越高的情况下，浏览器富客户端越来越流行，意味着浏览器很多的交互动作是通过js控件完成的，除了编辑集合的表格控件，还有编辑目录结构的tree控件，以及其他一些表达复杂数据结构的控件都有可能在应用中出现，仅仅靠form中的input来编辑数据，来提交数据，你将会逐渐落伍的。

有什么好吵的。我们现在都用flex搞富客户端。你说的各种js控件，各种取值，各种复杂企业界面，我从webwork开始到struts2到springmvc,在各种企业应用+web网站都用得好好的。这些框架都能实现复杂界面和取值，没什么实现不了的。能不能实现在于人。你说你写了那么个框架，自已用就是了。毕竟struts2,springmvc是大流，也很好用。

81 楼 hexiaodong 2011-04-18  

Agrael 写道

simon_zhm 写道

楼主到底有没有真正玩过jsonplugin啊，你第二个问题说的是问题么，jsonplugin的配置不是可以让你用正则来设置哪些属性返回，哪些可以不要么，再说了什么输入型参数，输出型参数，要关注这些干嘛呢，就因为这些微不足道的东西把struts批得这么不是，学习成本高？再高也没有自己重写一个高吧，模仿一个MVC框架的功能并不难，难的是你这么短的时间内，能写出具有通用性，扩展性的框架么

这里也能见到你-。-无处不在啊。
是啊，想想学习成本。。。。。我写的框架MVC部分的xml配置和注解配置都尽量向struts2靠拢，都是尽量减少学习成本。。。。。。

呵呵，你也是自己写mvc框架的啊。

在我写mvc框架的时候，webwork没有那么多插件，功能比现在的还弱，使用范围也没有这么广。所以很多年前就是自己写的了，也没想过向struts靠拢。

我觉得mvc本身没那么复杂，如果你不向struts靠拢，团队成员学习成本也许更低。就像我的框架，出了java-json映射策略需要配置，其他配置几乎等于0。学习成本1-2节课的时间而已。

80 楼 ice123456 2011-04-18  

hexiaodong 写道

我的同事或者下属不一定要和我差不多水平，他们不学我的框架开发，就只能学更复杂的struts1或者struts2了。
我的框架仅需要1-2个小时的学习成本而已，前端都是封装好的Js控件，一般都是需要编写的js代码主要有form.getValue(),grid.getValue()和tree.getValue()等等，然后把得到的结果提交到服务器段就行了。

我说的意思是你写的东西可能是对这些操作比较好的应用了。。但是并不能说明struts2  就完全没有可取之出。
一个框架肯定有它的优点与不足..不能因为它有种种不足而否认它的优点而已

而且框架既然被称为框架必然有大众化和通用性在里面.关键在于人去怎么使用它而已.

79 楼 hexiaodong 2011-04-18  

提交之后，你是用什么形式验证安全性和完整性呢？
在我的框架中json提交后被转换成java对象，然后在由java对象自己来验证就可以了。这个应该不麻烦吧。