http://dev.csdn.net/develop/article/85/85114.shtm首先声明的是，我是初学JAVA，对JAVA有一个基础的认识，近来由JAVA基础-jsp-struts这个过程一步一步的深入学习，但学习过程中我也发现STRUTS如文中所讲那样的确是一件非常郁闷的事情，配置XML文件是一件非常苦的事，自定义的表单语句也要在DW中安装插件，频繁的重启TOMCAT，这些现象在我初学STRUTS中都遇到了，所以我现在也决定不要重要的学习精力放到STRUTS等其它框架上去，把基础功再打扎实一些。当然每个人都有每个人的看法，不反驳反对者，意见平等。感谢
虽然struts开发比正常的jsp + javabean开发要复杂，但是，它为我们实现了MVC模式，使我们的系统具有更好的可维护性。
而且，对于动态表单，实际上struts还是具有解决方法的。
重启TOMCAT的问题，好象不只是STRUTS才有的，即使你只是写SREVLET和JSP，也同样要重启TOMCAT。
如果你只使用JSP，那么就正好说明了一个问题：业务逻辑与表示过份的耦合，十分不利于维护。这在一个大系统中是致命的。
如果STRUTS真的如此不堪，那又为何如此流行呢？
虽然struts开发比正常的jsp + javabean开发要复杂，但是，它为我们实现了MVC模式，使我们的系统具有更好的可维护性。
而且，对于动态表单，实际上struts还是具有解决方法的。
重启TOMCAT的问题，好象不只是STRUTS才有的，即使你只是写SREVLET和JSP，也同样要重启TOMCAT。
如果你只使用JSP，那么就正好说明了一个问题：业务逻辑与表示过份的耦合，十分不利于维护。这在一个大系统中是致命的。
如果STRUTS真的如此不堪，那又为何如此流行呢？
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
有一定的道理，目前还在学习JSP阶段
还不是很清楚
作为一种参考吧
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
Struts的巨大烦恼 真的不适合大系统？经过一段时间使用struts，随着系统越做越大，现在，我终于要抛弃struts了，因为到现在，struts的巨大不足和缺陷越来越影响到我的项目的进度和开发效率了。 背景：现在，我负责着一个大型企业的人力资源管理系统，整个系统管理的人员大约有1.6万人左右，系统基于jboss+oracle，java技术框架为struts，少许的报表用到了 servlet，项目开发的时间差不多一年，好，转入正题。 到现在为止，我认为formbean 的好处就是和页面表单对应起来,在系统业务处理中，可以实例化formbean之就可以取出页面表单的值来,方便于在业务逻辑中引用。使得业务处理层和展示层可以分离开来，到现在为止，这也是我发现struts的唯一好处。 但struts带给我的烦恼，各位，实在太多太多了，主要的几点我罗列如下： 一、转到展示层时，需要配置forward，每一次转到展示层，相信大多数都是直接转到jsp，而涉及到转向，需要配置forward，如果有十个展示层的jsp，需要配置十次struts，而且还不包括有时候目录、文件变更，需要重新修改forward，注意，每次修改配置之后，要求重新部署整个项目，而tomcate这样的服务器，还必须重新启动服务器，如果业务变更复杂频繁的系统，这样的操作简单不可想象。现在就是这样，几十上百个人同时在线使用我们的 系统，大家可以想象一下，我的烦恼有多大。 二、当页面表单需要自动变化或者频繁变化时。 对于一个成熟的MIS系统来说,页面表单肯定是不固定的,甚至象有些系统，页面表单是存在数据库中，需要填写的表单在页面自动生成，比如填写一个人员基本信息,本来只需要填写 姓名、性别、出生年月 三个指标，而我后来需要增加籍贯这样的指标，我只需要在数据库中添加籍贯这个记录，并在页面就能自动增加籍贯这样的表单。而 struts在这方面，其优势反而变成了不足，我参考了非常多的人力资源管理系 统，这些系统几乎都能够做系统里面就可以控制人员信息的指示，进行使展示层能随之灵活变化，如果使用了struts，这些灵活性就根本用不上。 同时，如果页面表单频繁变化时，就需要频繁修改formbean对应的方法和属性，而每次修改之后，就要求重新部署，或者重新启动服务器……。 三、要引入struts包，引入strtus标签库，现到现为止，我们有所见即所得的dreamwaver、frontpage、webeditor，对于繁杂页面的设计，是非常方便的，而对于struts标签库，没有哪一种软件能够支持。jbuilder我没用过，不知道支持不支持，而为了维护这些标签库，增加工作量支持，也非常容易出错，稍微不小心，就一堆异常抛出来，系统他死给你看。 总结： 现在为什么asp.net越来越流行，非常重要的一点，就是asp.net这样的模式，简单，易于控制。而且我现在仍然觉得，利用jsp的文件名作为路径的映射非常方便，而struts还非常去配置action,使之有带有象.do、.main这样后缀的路径访问方式，不但增加了系统功能的复杂性，影响了系统的性能不说，还增加了非常多的系统不可掌握因素。其实 javabean+jsp，利用javabean处理业务逻辑，只利用jsp来展示数据，这正是.net的原型，同样，即可以不用去配置struts、也不需要象serlet一样去配置web.xml带来的麻烦。 所以，并不是所有的框架都是好的，越简单越易于控制。
所以，现在，我决定放弃struts，转而采用javabean+jsp的技术结构
和楼上的大哥有点同感呀
无论asp.net，还是javabean+jsp结构，没有C统一的控制层，容易造成混乱~