最近用struts做了个项目，跟大家讨论一下心得，大家踊跃加入阿

别打消我学习struts的积极性啊！你这个活有多大？用普通的mvc设计模式要多就做完？

在大项目中struts 结构清晰，容易管理。javascript在客户端验证也是需要的啊！

好用的是action,actionform,message,error,
至于页面上的一些struts的标签,就没必要用了。
用struts框架开发的代码维护起来真的是很方便

一直觉的actionform不好用！老传不到值

楼主和我是同感啊!hands:)很多人说struts好,于是我试着来用了一下,发现比JSP+JavaBean模式复杂多了,更不能容忍的是什么多西都要到服务器上去完成.(比如页面输入的有效性验证,当然也可以写JScript,但麻烦点.)这个感觉速度就慢下来了啊.另外,struts可以看作是对JSP的一种封装(它的Action,Form概念算是其自己定义的一种开发流程模式而已),感觉上编译速度就慢了不少,不爽:(最后偶弃用了它...

历史告诉我们，要辩证地看问题。中庸为天下正。
1) 标签库限制的太死......的确，标签是struts的一个糟人非议之处，学习曲线也很高。不过我认为，它并不存在你所说的“限制太死”的问题，他的标签中留出了绝大多数html中的表单元素属性，你的低效在于你还没有足够了解它。2) 错误验证比较麻烦，struts希望可以在服务器端做验证，当实现起来远不如用javascript在客户端验证来得方便。这一点也不够充分，我是一个程序员，我的js经验不足，所以我乐得用struts的验证机制，用js验错通常会alert出一个消息框告诉用户哪里输入得不妥，我曾作过一个外包项目，人家的UI准则中明确指出，弹出框报错是不友好的，不许使用，通通用显示在表单页面上的报错方式.想想也有道理。弹出一个窗口的时候难免产生一点紧张和郁闷。3)从代码量上来说用struts也比用普通的jsp＋servlet实现来得多，比如要多些许多formbean，还不如在servlet直接getParameter好用。如果说前两个楼主还有一半的道理的话，这一点尤其离谱。依你的理论，何必绕来绕去研究什么设计模式，搞那么多类又继承又协作的，何必面向对象。无言的山丘......

谢谢 _chage(青之六号) 兄如此详尽的回答！首先要说明的是我的这个项目的规模应该算中等！
我想说说我这个项目的架构：web层（jsp页面)－－struts层(包括formbean和action)－－business层（包括业务处理类和业务值对象）－－DAO层（所有数据库连接操作），这应该是一个架构比较清晰的工程，不知各位大鸟有什么见解！
我想说的是：
１）　在ｓｔｒｕｔｓ页面中如果不要ｓｔｒｕｔｓ标签，formbean是得不到页面中text的值的
2) 　用ｊｓｐ+servlet也可以实现非常清晰的架构，action不就是一个servlet，struts中ActionForm是用ｊａｖａ反射实现text到bean的自动填充的，自己写个类完全可以实现一样的效果！
３）不知formbean实现了什么模式，起了什么作用，我的感觉不是很深刻！即使用formbean,也需要从bean中get出来，跟servlet的getParameter差不多的效果！

我有一点和楼主有同感就是struts的标签库限制的太死，不如hmtl灵活,好多要慢慢摸索.但优点还是多的,它条理清晰我觉的是最大的优点.

感觉小项目还是用jsp+servlet来得方便。
HTML是大多数人都用习惯的。加了STRUTS的HTML标签用起来是不是很舒服
看个人用法了。
STRUTS的传值的确有点费神，对于刚开始STRUTS的人来说

要是所有代码都是你一个人开发，
当然是感觉难度增大了不少！
要是好多人一起开发，感觉就是不一样了啊！界面和逻辑分开是最大的优势！应该是吧，用struts，美工不需要太多的学习，会作html的就能作struts的界面！
而jsp责不然

大家说得都很有道理，我用struts用得也不久，感觉合作开发还是比较方便得，喜欢他的国际化得功能。如果一开始经验和基础不是多好的话用struts可以轻松得实现架构清晰得程序，当然如果你能力强，完全可以自己实现action得功能，也可以自己定制标签，struts对于项目得维护还是非常方便得。

2) 错误验证比较麻烦，struts希望可以在服务器端做验证，当实现起来远不如用javascript在客户端验证来得方便。
struts的validation插件不知道你用了没有，比你写js代码好方便的多，而且安全。3)从代码量上来说用struts也比用普通的jsp＋servlet实现来得多，比如要多些许多formbean，还不如在servlet直接getParameter好用。你可知，你写完以后，修改有多方便。

我想问huhuandnini(胡胡) 一句！你们的美工帮你做带有struts标签的jsp页面？

１）　在ｓｔｒｕｔｓ页面中如果不要ｓｔｒｕｔｓ标签，formbean是得不到页面中text的值的
答：是可以获得text值的，就算你在地址栏后面用？挂参数，formbean仍然可以得到对应的值，不过不能在回到此页面的时候把相应的值设回来而已2) 　用ｊｓｐ+servlet也可以实现非常清晰的架构，action不就是一个servlet，struts中ActionForm是用ｊａｖａ反射实现text到bean的自动填充的，自己写个类完全可以实现一样的效果！
答：Action不是一个servlet，只不过是ActionServlet中间调用的一个方法所在的类而已。整个Struts的核心就一个ActionServlet。struts中的确用到Java反射，但是人家有现成的你为什么要自己写一个呢，光一个<bean:write>的TAG你想写成它那种功能都要你够呛。３）不知formbean实现了什么模式，起了什么作用，我的感觉不是很深刻！即使用formbean,也需要从bean中get出来，跟servlet的getParameter差不多的效果！0
答：当然不一样，用formbean便于使用重构，你用getParameter的话如果改一个参数，哪边忘记改了以后编译都编译不出来，非要等到运行的时候再一次次DEBUG总之，我觉得Struts模式非常好，现在基本上如果项目中不准用Struts的话（目前还没有遇到过），我都觉得写JSP很痛苦了

“错误验证比较麻烦，struts希望可以在服务器端做验证，当实现起来远不如用javascript在客户端验证来得方便。”validation就支持双验证。可控制是否在客户端验证。而且，在validation里还支持正则。我想，楼主应该是没有用吧！“不知formbean实现了什么模式，起了什么作用，我的感觉不是很深刻！即使用formbean,也需要从bean中get出来，跟servlet的getParameter差不多的效果”扩展一下DynaValidatorForm，自己写个bean，在配置文件中只要写上需要的name。就能自动生成动态的formbean，就不用写实体bean了。（呵呵，这个我现在也不会。是公司的前辈扩展的框架，借了过来和大家一起交流一下）

TO alanfisher (西湖醋鱼)
  你的困惑当初我也有过,这是很正常的.现在做的工程多了(其实只有5~6个^_^),对于struts我觉得有以下感想:
  1:struts最重要的是体现一种MVC的框架化简单实现的实现思想,毫无疑问虽然在使用它的时候是比较烦杂的(实践证明效率也是差强人意),但是它的框架无疑是比较成熟的,它使得你可以将更多的时间与精力放在程序实现的细节上而不是整体框架的设计上,其错误的页面显示机制我觉得也是比较友好和完善的.
  2:struts的标签库限制使用起来是比较繁,但是这是一种规范的标志（我们很多程序员往往对规范化的编程方式不屑一顾，这可是不对的哦）,其检查的严格可以使错误发生的几率降到最低，当然有得必有失，你要规范就得多写代码
  3:写起来是麻烦点,但是维护起来可是简单多了.现在的程序编写维护是重要的一环,单单冲着简单维护这一点相信就有理由用struts了
  4:对于一些中小型的工程,用struts可能觉得有点累赘,但是对于一些极其正规的大工程,struts可是好处多多,规范的写法使得程序易读易维护,采用ApplicationResources.properties文件实现国际化,使得程序的页面显示可以很容易的替换为其它文字,对于在不同国家发布版本极大的减少了工作量.....
  小工程我不敢说,反正我觉得大工程采用struts是很有必要的,而且如果单从程序员本身能力发展着眼未来来看的话,建议用struts是个很好的练手机会,对将来的编程道路有莫大的助力...(当年我的第一个工程用的就是struts技术,当时国内根本没有strus的中文技术资料,为了编程查看的方便,我们项目组于是硬是把英文文档翻成了中文,只是限于公司规定一直不能发到网上公开)

确实国际化方面struts是做得很不错的！to dlxu(沿着Java继续前进) :
1) Action不是一个servlet，只不过是ActionServlet中间调用的一个方法所在的类而已。光一个<bean:write>的TAG你想写成它那种功能都要你够呛。
答：Action确实不是继承HttpServlet，所以不是一个Servlet,但它起一个控制器的作用（我将业务逻辑分出去写了），所以相对于一个Servlet。其实<bean:write>等的tag用jstl里的标签完全可以替代，而且做起来感觉还灵活一些。我当然不会自己去写标签库。2)用formbean便于使用重构
不是很懂阁下的意思，可以再讲详细一些吗？感觉现在真正考虑做重构的公司很少哦！

醋鱼兄，我再补充几句。在layer的划分上，struts是属于表示层，它的mvc中的model指UI所需要的数据模型。formbean的作用是比较尴尬，它肯定不能承担这"m"，它在验证和把表单元素自动收集上体现了价值，你在上面说，觉得formbean的这个收集表单元素的功能还不如你自己来getParamter，呵呵，我举个例子，有很多持久层框架(如hibernate)作的事情，仅仅是把关系数据库中的表行数据映射为object,因为这是两个不同的事物，表单上的一个个元素和我们所喜闻乐见的"model“无疑也是两个世界，formbean拉近了它们的距离，还是自动的，不好吗？
    功夫在诗外，struts是一个小小的局部，还有更广阔的世界等着我们去征服。
    注1：我现在真的觉得struts太”重“了，甚至是丑陋，当我了解了webwork和spring mvc后。不过有很多技术之外的需要考虑，例如人力成本，例如新技术风险
    注2：你可以看一下csdn blog电子杂志中的这一篇：struts最佳实践，提及了一些大局观的东东： http://blog.csdn.net/emag_java/archive/2005/01/13/252036.aspx

Struts 的优点关键在于构建大型的程序，因此，如果你做的项目小，感觉会麻烦，试想如果一个20人以上共同开发的项目，如何来保证程序结构的稳定呢？
我也感觉标签库不好，因此，我只用它的流程控制

听说Struts 的优点关键在于构建大型的程序，我井底之蛙，从没有见识过什么“大型的程序”,
那位大哥做“大型的程序”的，说说，这里有做“大型的程序”的么？

1.个人理解,少于100个pages的应该不算"大型的程序"吧:)2.struts的优点可能也是它的缺点,如有效性验证,使用方便带来的后果就是速度缓慢.3.本身struts作为web服务的第三方开发包,就是对web的一些封装,既然是封装,效率也会降低吧.(我个人非常看重页面浏览和处理速度:)).4.第三方开发包的加入,导致和web server之间有一些东西不太兼容,web server的控制台上好像经常出些莫名其妙的warning,由于是封装,所以,我们想去掉这个东西好像不是那么容易.(web server的warning过多是不是也会影响web server自身的效率呢?)5.多人同时开发的时候,大家都一起修改struts-config.xml是不是也非常容易引起混乱啊?(可以支持多个配置文件吗?我只一个人开发过,每次都是修改那个struts-config.xml,所以能否支持多个struts-config.xml不太清楚,我待会去查查看).6.简单本身就是一种美,过多的封装违反了java的本质精神.java本身在效率方面已经被无数人诟病,我实在不想让其雪上加霜啊:)多谢指教!

另外,又想到一点,struts好像对单表单的提交处理或者数据库单表的维护这种典型模式处理得
炉火纯青,不知能否支持对多表单的同时提交,不同frame里面的不同表单的部分提交,数据库多
表联合维护(查,增,删,改)这些方面的功能怎么样?欢迎有用struts使用过这些功能的朋友交流一下感受:)

struts的验证已经做得很好了，你可以用服务器端的验证也可以用客房端的验证。validation这个你用过没有，这是很好用的。
struts的标签一开始是很难学，可是学会了，还是很好用的。总体是利大于弊。要不也不会有那么多人用了。虽然我在学struts上也花了不少时间，但我觉得值。

呵呵，其实struts蛮好的，现在叫我丢开struts这样的框架，直接用jsp和servlet,我会感到非常吃力。MVC是一种思维习惯，当你看到一个页面的Form,你就会先想到后面的ActionForm.我们做系统设计时，都是先出ActionForm,再考虑页面如何展示这些ActionForm里面的属性，而不是先去想页面，然后根据页面去写ActionForm。
1.ActionForm对数据的封装在页面Form元素比较多的情况很实用，比如20-30个parameter,你用getParameter的代码要写20-30行,而且写错了Parameter名字还没有提示，ActionForm和页面标签配合使用就没有这个问题，你的标签属性名和ActionForm不匹配，那么页面就会有错误输出到日志文件。
2.ValidateForm的交验，如果要我选择服务器交验和客户端交验，我肯定放弃后者。为什么？因为javascript运行在客户端，客户可以选择不执行javascript.就是说js交验只能起方便用户使用的作用，对一个安全的程序来说，服务器端必须做，客户端交验是选做的。如果不通过struts做验证，工作量只会加大。同时我要说，struts validator 可以生成js交验代码。
3.对于分层的结构，那个ActionForm根本就是跑不掉的，它的对应物是传统MVC的javabean,如果你的项目不要用Bean,那么是可以不用Struts了。

关于java的效率，我想java是把易用性和效率结合非常好的。我没有听人说过java web server的效率太低的问题。一般的中小型系统效率问题集中在数据库一端，如果你的程序大量使用数据库，你可以看得出来，数据库联接的获得和查旬操作是最慢的，是可以用秒记的，java运行程序一般是毫秒级别。java不慢，java只是费内存。另外，对一个写的不是很烂的程序（效率上）去做优化花费的成本恐怕够买几个服务器了。

项目大小，我觉得主要看user case多少，不是看页面多少。

To:death0320(死亡金属)
我没有否认validationd 的易用性,只是对为这个validation付出服务器端的资源代价值得不值得而已:)To:slaser(沧海月明)
MVC是一种模式,JSP+JavaBean没有否认这种模式.(struts的ActionForm与ValidateForm只是对Bean的更细的定义而已).你的对ValidateForm的说法还比较有意义,对安全性要求高的应用应该是你的做法.我说的web server的效率问题是指Tomcat,WebLogic等这些东西的效率问题,通过它们编译的东西越多,它们的任务量就越大,速度就越慢.你也说的对,数据库的操作是很最耗资源的,我做的大部分应用都是DB相关(而且数据量一般都非常大),所以对效率的要求更是比较苛刻点,即我可以容忍DB操作对资源的占用(这个是对DB操作优化后无法避免的代价),而无法容忍一些不是非得占用服务器资源的请求来浪费宝贵的网络带宽资源与服务器资源:) 另外,项目大小按user case来看也是对的,不过一般来说,user case的数量大多和pages的数量成正比关系吧,所以我们的说法都没有错:)

看了slaser(沧海月明)兄的一番解释，还是明白了不少！
还有一点就是各位在做ｓｔｒｕｔｓ的时候可不可以不用他的　标签库，而改用ｊｓｔｌ的标签库，因为ｊｓｔｌ的标签库确实是比ｓｔｒｕｔｓ的标签库好用许多。如果可行，可以谈谈一些技术细节吗？

对于各位的发言，我总结了一下：
１）ｓｔｒｕｔｓ用在大项目上才会真正发话他的优势！
２）从逻辑上来说ActionForm是从表示层到页面之间的数据传递对象，从设计时，也是先出ActionForm,再考虑页面如何展示这些ActionForm里面的属性，所以ActionForm还是非常需要的。当然，我也认为jsp+servlet+javabean也可以实现非常独立的MVC模式。
３）从错误验证上说，虽然ｓｔｒｕｔｓ错误验证在服务器端实现，从效率有所不及，但从安全、人机交互角度说还是非常有用的！而且，一旦熟悉的Ｓｔｒｕｔｓ的错误验证方式，做起来也是很方便的！
４）从效率上来说，其实真正的效率问题在于ｄｂ操作上，相对于服务器端错误验证来说！

看了大家精彩的讨论，我也想说上两句（我是个struts的初学者）：个人感觉：jsp+servlet+javabean这种开发模式任何人都可以形成自己的风格，写起来也是随心所欲，这样在合作开发的时候难免会出现很多问题。在维护的时候也会显得极其费力，程序的整体框架也显得不清晰。继续关注大家讨论.........

我再继续，^_^.还是针对醋鱼兄的总结吧，
1. struts 用在大项目上才会真正发话他的优势！不完全同意，要看这个web应用有没有较为复杂的逻辑，如果超100个page,但基本上没有业务逻辑，只是平行的增删改一百张数据库表，这样也体现不出来优势，struts是分层架构的一个局部实现。
2 and 3 strut之“重”，在于它需要负责的东东太多，而且各部件间耦合较为严重，我曾经见过团队只用它的action转发，标签库和formbean都没有用到。严重不同意其作法，既然付出了这个代价，当鮁要把struts的潜力全部逼出，formbean,异常机制,验证一个也不能少，否则，干脆用webwork好了，再不自己写一个，也不复杂，好些讲mvc的书上都有actionservlet的简化版实现。
jsp+javabean+servlet当然能搞出mvc了，struts不也是构建在这三者之上的吗，一般Model1指的是jsp+javabean。
4.效率？性能？我觉得得持科学严谨的态度，不能想当然耳，用数据说话，数据当然是指严格的测试结果。

学习中...初学struts..觉得超麻烦,规则太多......完全不能按自己的想法办事!~

我不赞成楼主的说法的,细看眼下的用java开发的软件公司都是用Struts框架的.现在它已经成了java界的主流框架,至于他的好处就在于它把我们的思想统一起来,把我们规范化!
小弟我是绝对支持Struts的,直到有下一个更先进的技术面世之前!

我用struts仅仅使用了其C这一部分。M和V都是自己写的。V部分因为对JS、HTML比较熟悉，加上部门内部的人上手也容易，所以大家都没有使用其标签写法。M部分我们是自己封装了一些函数，使用起来也很方便。
想去想来，就只使用到了STRUTS的C。

关于验证的问题，最重要的一点却没有人提到。
那就是，永远不要相信客户端验证！！！！！！！客户端验证是不可靠的，用户完全可以关闭JavaScript那样客户端验证将完全失效，另外，如果验证的数据比较关键的话，如果用户想要Hack掉你的系统完全可以自己发一个HTTP请求绕过你的校验，因此，无论什么时候服务器端校验是必须的

调试易

最近用struts做了个项目，跟大家讨论一下心得，大家踊跃加入阿

解决方案 »