楼主，既然你认为struts 不好，当初你为什么要用?别人说他好，基于别人的经验或许还有你所说的跟着下吆喝，那你为什么不经过验证就采用？在采用某个框架或者新的技术之前，没有对它的优点缺点以及采用以后可能带来那些风险进行评估，就跟赶时髦一样用，即便这样，用别人的东西就应该好好研究该怎么用，一旦遇到什么麻烦，采用泼妇似的谩骂不能解决任何问题。

另外，你是从什么地方得出的结论我没用过struts? “猜想”？ 我觉得这个问题上跟你对struts的态度一样，没有真凭实据就得出结论。

To:inprise_lyj 我目前的项目采用的webwork，限制比struts少一些，但是用起来感觉都比较方便.

希望wild fox 能另外开辟一个主题讲讲webwork 与 Struts 的区别，和他们的优缺点，行吗？

刚接触webwork不久，还停留在“能用”的水平，项目时间比较紧，还没有来得及仔细研究，不敢妄下评论，不过因为WebWork和Struts都是对模式2提供的解决方案，感觉比较相似.opensymphony 上有一篇对两者的对比http://www.opensymphony.com/webwork/wikidocs/Comparison%20to%20Struts.html

xuesenlin说的倒确实不赖 其实我也没想说的很过分 可能我这个人爱憎分明比较分明吧 所以...
言辞是激烈了点 struts毕竟作为一个公认的框架确实有一定的约束作用

不管怎么样在技术层面上 一个人说真话不应该被责备 对wild fox 我没什么好比说的!

框架当然有很多好处，其实用的太多方而确实会效率下降，而且为了框架你会被迫去适应它，结果造成程序一篇混乱，反而变得繁琐。但有一点是对的，核心mvc框架用别人的就可以了，其它的还是自己来，这样有两个好处，你可以轻松自如的控制每个细节，同时降低这个框架的风险。

我觉得楼主是刚从微软转过来，关于java的开发还没有入门，问的问题都很幼稚，可以理解

慢慢都习惯了。
struts不能全用的,我只用他的action，标记我用的很少

用struts+hibernate开发一年时间了。
感觉还可以。但我最初也没有楼主那种感觉。
可能是一开始我就没全用吧。
hibernate我从来不用一对多多对多什么的。

我觉得楼主是刚从微软转过来，关于java的开发还没有入门，问的问题都很幼稚，可以理解 ============================================

老兄 我拜托你 什么东西不是越麻烦才是越高级的 我看你先到一边想想再说吧

ytok2000
火气蛮大吗，其实别人这么说对你个人并没有任何意义，一切都在你自己手中，struts只能说对你不合适，但这不能否定一切，也不要闭口开口就什么是垃圾，如果你能设计出这样的“垃圾”，可能会有资格这么评论，不然只能显示你的无知。

换一种新的技术从短期看肯定会造成效率下降,需要长期的积累的过程.从系统设计的角度的来看MVC结构是必须的,即使你用.net开发也一样,也需要借鉴struts的设计思想.asp可能上手是比较快，但是我现在再维护一个以前的asp的系统的时候感觉非常麻烦,系统在做性能优化时几乎无从着手.

.Net是个不错的东西，比较起来，微软的开源的确可以培养一大批微软型程序员，可以与JAVA相媲美，不过在学习难度上就比JAVA容易多了。

是否复杂麻烦要看对struts如何应用。struts核心思想很简单，一个servlet(controller)接受请求路径，根据xml配置文件获取对应action(command)，执行它，执行完后跳转到配置文件指定的页面。这是大部分mvc框架的核心思想（包括webwork2，基于spring的mvc实现等）。（再退化一步，取掉xml配置，就是我们公司2001年开发的那套程序的原始架构，所有请求都通过一个jsp统一进行跳转。）去年我们做项目的时候，因为其他的队员都没用过struts,所以我们就取上面最简单的应用，舍弃其他mvc外附加的功能（包括formbean,validator,tiles等等）。所有队员都在 1-2天内就可以进入开发，没觉的有什么关于struts的问题（包括毕业生）。当然在提醒了一些应该注意的地方后（比如struts把action实例cache到一个hashtable里面，所以action应该是无状态的）。至于xml配置的麻烦，关键要对各个module分好功能，名字规范（比如request path: guest.do对应request.jsp),再结合xml ide,都可以很方便的进行开发和后期维护）。

我觉得楼主认识有问题.不要那自己干了5,6年的软件拿来当依据.struts用来没有说过能够一定减低开发强度,它是工具会不会用是人的问题.
作为一个软件公司,你开发的产品是要来卖的,也就是说你卖出去的东西,收了顾客的钱你是要负责的,struts的MVC模式显然是比较合理的模式,这点大家都不会怀疑.还有,作为一个软件公司,不要把case当case,既然他是你的,你应该给客户一个好的架构,这样以后客户有需求你就可以在这个架构上扩展,或者说隔1,2年给客户重新把原来的系统改善,我强调的是改善而不是重写,顾客很少会答应重写的,客户喜欢的扩展.不要为了做程序而做程序,看看软件之外的东西,在我们写每行代码的时候.

看了大家讲了那么多，
我也想说两句。
Struts本身来讲，还是不错的。
一个事物，有其存在的原因和环境。
Struts是用来解决页面的流程控制的。
同MVC的主要功能是一致的。

在struts1.1以后，提供了很大的自由空间，
很多地方都能用自定义的类来处理。

在我们的项目中，采用了Struts，
我认为，我们得到了益处。
我们的分工很明确。
比如：
有人专门在做MODEL
而相关的V C部分则是其他人做。
由于M层提供了接口出来，在其实现之前，
却不会影响V C。
这样，整个项目一直处于并发的前进状态。

这肯定会缩短整个开发周期。

也就是说如果分析做得好的话，
采用Struts将事办工倍。
前提是需要对Struts熟悉。