struts带来的巨大烦恼…是不是系统做大了都不能使用struts?

也许楼主还未体会到struts的精妙之处，如果在你引用了struts之后却还是跟未用之前一样的编程习惯，那出现这种情况也是必然的，至少我在几个大的项目中未遇到楼主所说的烦恼，相反，struts对大系统来说，更得心应手些，会大大提高工作效率。一、转到展示层时，需要配置forward
这个是必须的，我个人看来这不应该被认为是蹩脚的地方，你认为的直接转到jsp一般来说应该是极少部分吧（在你看来应该是大部分），如果项目中经常出现目录、文件的变更，那只能说明是项目控制的问题了二、当页面表单需要自动变化或者频繁变化时。
难道你的数据库表结构会经常变化吗？
这个或许归为设计问题了三、要引入struts包，引入strtus标签库
网上有dreamweaver的struts插件，但我也没用过呢，不过我倒是觉得没太大必要，毕竟标签书写也不是太复杂嘛经过这么多年的考验，struts却仍旧这么经典，你不会认为在struts应用当中只有你们才做了个这么庞大的系统吧

谢谢楼上的：
页面的表单如果我需要动态生成，同时把系统的跳转路径都存到数据库里面，struts根本无法做到啊！，对不对？
对于成熟的系统，页面表单无法固定，因为数据库的指标和字段，都交给用户自己去维护，而且是要通过一个系统的后面来进行维护，而不是用户要加一个指标都得通过程序员来添加，我不知道楼上的有没有做过这样的系统，这样的功能已经很流行了。
我现在只想用最简洁的开发工具，一个项目来说，效率和速度是非常宝贵的！整天花心思去找那些第三方插件，太浪费时间了，难怪很多用了第三方插件的项目做一个死一个。

JAVA体系中套上了若干框架后,从本质上来说,代码会复杂一些,带来的好处便是思路逻辑更清晰;Struts核心的任务除了FormBean中的属性与页面元素相对应外,最重要的逻辑便是Action之间的匹配及如何跳转;的确有上述楼主说的一些问题,但有办法可尽量解决的,如:很多改变可以不重启动服务器Tomcat,在conf/server.xml中将Project的Context的属性reloadable="true",引擎就会自动重载;Struts的FormBean中如果涉及到复杂对象的属性的读取会更麻烦,这与Webwork框架的Ognl自动拦截器相比又更麻烦些;

正如：silverend朋友说的，好处便是思路逻辑更清晰，的确有这样的优点，但如果系统做大了，做得更灵活了，struts反而不灵活了，同时，这样的开发效率低，每一次改动都得·＃￥％……—＊…，一年下来，我的系统被struts拖累了。

其实楼主说的对，用了框架确实麻烦，动态表单的确实无法做到，所以说，做大项目肯定不能用这个东西的，许多大的公司都是自己的开发体系，不用这些东西。我曾经参与开发过几个项目，虽然不是用java，但也是自己写的开发体系，基本所有的东西都是数据库里定义的，一切管理的就交给了管理员，而不是程序员。就像楼主说的，我突然想加个“籍贯”只要管理员自己填写就可以，同时还可以自己设置字段有多长啊，是否必须添加啊
但是用了框架struts就会非常麻烦。其实个人觉得要做大项目必须自己开发框架，不能用这些，这些东西只能做点小网站，小系统可以。
欢迎大家拍砖。。

对，楼上就对我的问题深有体会，同时，相应的麻烦还有struts配置、forward配置等的，总之觉得，struts真缺点还不少。

一、
象2楼说的,你的项目控制的问题.
想要真正,完全满足你的"动态部署"的要求,只能全部用jsp了,难道所谓的大项目就是只用jsp的项目???二.
应该很少见吧,而且这和struts有什么矛盾么?你不喜欢ActionForm就不用,struts又不强迫你使用,.
如果你的项目里大量的表结构都是不确定的,你还做什么开发啊,做一个动态crud的基础框架,把表一建,整个项目就完成了......你nb了.三.
同上,不喜欢struts tag 就不用,jstl多简单,漂亮.最后说一句,觉得ruby这样的动态语言是比较适合楼主的需求的.
对于楼主的第2点不满,使用rails--ruby的mvc框架,只要建表就成,一行代码都不用写,一个页面都不用建.

<<<页面的表单如果我需要动态生成，同时把系统的跳转路径都存到数据库里面，struts根本无法做到啊！，真的无法作到么,你不用struts又是怎么做到的?这是设计上的问题.
<<<对于成熟的系统，页面表单无法固定，因为数据库的指标和字段，都交给用户自己去维护，而且是要通过一个系统的后面来进行维护，而不是用户要加一个指标都得通过程序员来添加晕死,原来所谓"成熟的系统"就是所有的表单都不确定的系统......
先不论是非(显然,这样的系统业务逻辑必须非常简单),你需要的是一个根据数据表动态实现crud功能的中间层,它的web层可以基于struts或其它的mvc框架.
如果要实现比较复杂一点的业务逻辑,或许drools这样的Rule Engine可以对你有所帮助,当然,它和web框架毫无关系.

struts笨重麻烦些 formbean不好还是用webwork吧

谢谢 Saro　朋友拍砖，我说struts不适合大系统，用javabean+jsp，也不代表大项目只能用jsp啊，我认识一个真的的项目，由于业务变得非常快，用户还真的只使用jsp来做，整个项目跑得稳稳当当的哦。
　struts固有的这些缺陷，真的不适合大项目，虽然您批驳了我一下，可也没有真正解决我现在所面临的问题，不能为了技术而技术哦，应该是为了解决实际工作需求使用真正合适的技术！
<<<页面的表单如果我需要动态生成，同时把系统的跳转路径都存到数据库里面，struts根本无法做到啊！
　这的确是事实，对于工作流的系统而言，在数据库中保存程序的下一步转向是很重要的工作，不知道您做过工作流软件没。

同感，
有些东西用了struts真的不如jsp+javabean快，
用了struts，老是想着jsp+javabean的自由。

楼主，我们正准备着手做一个J2EE的项目，是一个在.NET平台上很成熟的系统要移植到j2EE平台上，也有楼主上述的第二条业务流需求。我们刚起步作，公司的哪帮人还说原来的平台没有做到MVC模式，希望我们在J2EE平台上能够做到这一步，看了不少框架的资料，正准备用Struts呢，看了楼主的帖子，比较灰心了，实现MVC需求和动态表单，困扰了，非常希望能与楼主交流，我也想少走些弯路，我的MSN是[email protected]

可以使用tiles技术，至少修改jsp路径的时候方便一点formbean用动态表单，如果是一个基本表，可以设置<form-property>的类型为PO，然后jsp页面通过struts标签 <xxx.属性>，action就不要一个个接受表单元素了其实struts还是比较方便的，你可以做自己的标签，比如分页什么的，一个框架能存在这么久，说明有点还是大大的～相信你比较熟悉struts，所以我一带而过了

这问题和struts 有什么关系啊，这就是一个效率和目标问题，比如你说管理员动态加籍贯得问题吧，那除非你设计一个主表。一个辅表，辅表记录名称和属性，这样又不符合数据库范式了，“难道你的数据库表结构会经常变化吗？这个或许归为设计问题了”struts 等框架得精华是一种mvc 得实现，不喜欢使用标签就可以不用struts得标签啊完全没有问题得。个人意见。我觉得楼主稍微看得远一点。任何东西都要消化和吸收，因为客户需求千奇百怪，所以好用得就用，不好得就自己扩展下。

谢谢楼上几位朋友的建议，yinzhe　和struts没关系？呵呵，正是struts的不足，所在严重影响了我们项目的进度，也限制了系统的扩展性。不是我不喜欢struts、对struts有什么偏见，而的的确确struts有这方面的严重不足。
　所以，我觉得，大家不要盲目相信所有的java框架都是好的，只有合适的选择才是正确的，struts就有很大的不足，就限制了项目的进度，如果再加上 hibernate、spring……，那简直不可想象。

donmy0620　朋友，我也不是完全反对struts，如果系统比较小，系统灵活性不需要考虑的话，到是可以考虑一下struts，但如果项目比较大、系统的需要非常高的灵活性的话，就不建议用struts了，其实，java是的灵活性非常高，而如果用了struts、hibernate这些东西的话，凭我近一年大项目的经验，这些框架反而限制了系统的灵活性，而且也提高了系统的复杂度！

谢谢回复，我们这个项目因为是其实本来不小，但是我们只是做平台迁移，前期的需求，分析设计也就没有了。前期我们只是消化它们的系统和思想，转移到java平台上。他们原来系统在.NET平台，几百个form使用了因为相似形高很多使用了同样的处理方式，这个如果使用java框架的话从你的说明来看好像会出问题，如果是这样的话，我们起步也就不用这些技术了。

使用struts就一定要有mvc的设计概念。楼主的一些问题可以归结为设计问题。而不是struts的问题。表单需要动态，需要动态修改formbean，那么你的数据库呢，也需要动态添加修改字段吗？关于跳转，要在配制文件里面配制，的却是比较麻烦，而且每次部署很困难，不过这都是开发期的问题，而不是运行期间的问题。难道运行期间你还需要去重新部署？用java开发，只要使用了tablig，目前还没有发现比较好的所见所得的编辑器（或许是我孤陋寡闻了）。PS：建议楼主看看webwork，这个框架要比struts优秀，省掉了那麻烦的formbean。

用webwork吧，　struts的下一个版本是以webwork为基础的。也就是struts action

好象我们的系统就支持表单定制，呵呵，楼主的思路被db里的表给限定了，想一想如何让db里的表支持定制功能！

表单定制???
页面布局如何? 难道就一行一列?能满足定制需求吗?使用velocity做页面感觉比标签库和jsp都有效.

当然webwork比struts好用,肯定也有缺点
缺点多是正常的,因为用的人多所以才能发现它的缺点多呀

只想问楼主有没有在Action里写过下面这样的代码：
public ActionForward index(ActionMapping mapping,
                             ActionForm aform,
                             HttpServletRequest request,
                             HttpServletResponse response) {//do something
return null;
}2. public ActionForward index(ActionMapping mapping,
                             ActionForm aform,
                             HttpServletRequest request,
                             HttpServletResponse response) {//do something
return mapping.findForward(request.getParamter("forwardpage"));
}
你看到action里的无处不在request和response没有？？？
javabean+jsp操作的不也是request和response么？
你在action里一样可以直接操作它的！！！struts能够做的事情有限，但是struts把所有需要的东西都提供给你了。
不要把自己的思路局限于formbean和Forward！！！不要一用了struts就以为struts里不能够写 request.getParamter和response.sendRedirect了！！！

谢谢各位的拍砖，看着各位都是星星点点的经验值，小弟还真的惭愧。
各位都在想办法解决这三个主要问题，而这三个问题，都涉及struts的核心，各位的做法，几乎都已经摒弃了struts的优势，这样做，在系统里面有一个似struts非struts的东西，还有什么用呢？就算系统里面保留了这struts，还不如不用。

晕呼呼...再随便说2句了
1.struts 是一个mvc框架
2.mvc模式分离了表示层和业务逻辑层，它使视图（你可以使用jsp,velocity,free)，视图流转(spring webflow 主要关注点就是这个)，业务处理得到了有效的隔离(在action 中被转发给bussiness bean)。
3.mode1(jsp+java bean)唯一的优势是对于小项目的快速开发，仅此而已。它的问题是:把视图绑定到了jsp,页面流转的处理分散到各个地方，java代码和html代码的混杂(业务逻辑和表示逻辑被混在一起),无法被测试!，无法维护!。这些都是致命的弱点。
4.楼主该花点时间看看书了，推荐2本，<j2ee核心模式>，<j2ee设计开发编程指南>(注意看4，12章,不过中文版翻译得很烂，结合英文版看较好)

支持楼主，我用struts用的也比较烦。
楼上说的：“mode1(jsp+java bean)的问题是:把视图绑定到了jsp,页面流转的处理分散到各个地方，java代码和html代码的混杂(业务逻辑和表示逻辑被混在一起),无法被测试!，无法维护!。”
JSP页面本身就是一个相对独立的东东，可以说你完全可以一个一个JSP页面单独测试！
struts就好维护么？稍微要绕一点的页面就得一堆Action和ActionForm外加配置文件！
还不说因为struts把VC层分的太严格经常使人对M层无从下手：Action要不要有业务逻辑？要不要PO、VO、QO、BO...
烦！

“当页面表单需要自动变化或者频繁变化时。”
这种情况可以不用formbean，可以弄个配置文件动态生成页面内容，根据配置文件来取表单的内容struts的用途是提供统一的访问入口，易于控制，比如权限控制，可以放在action中，然后跳转到各个jsp, 控制集中，代码复用，不用到处写这些代码

1.MVC
2.可以实现
3.手写页面很难吗？

看来，真正在使用struts的人才能发现struts的不足啊。

楼主的问题是，碰到不知道怎么解决的问题，就赖struts。一年的大项目经验少得可怜，struts存在很久了，5年已上了，应该有六年了吧，比你用java的时间长吧，应该自己反省，工作流谁没做过，动态页面谁没做过，struts很好解决了，有问题解决，不要来发牢骚！！

看到了大家的讨论受益匪浅，我是初学者，我个人觉得STRUTS还是有缺点的，就是难学，难理解太麻烦，^_^，要是根VB是的就好了

很多朋友都在说struts好，规范，mvc严格，其实，正是由于这些规范，限制了系统的灵活性。欢迎大家访问我的blog，继续讨论这个问题。http://blog.csdn.net/daveeyang/

死用框架是不行的，需要对框架进行再包装以适应你的具体的某个应用开发。一、转到展示层时，需要配置forward
   配置forward并不是一个很复杂的事情，页面应该是相对固定的，配置次数也是固定的，所以配置不是问题，关键是你能不能让你封装过的的框架自动跳转到相应的页面（而不是在你的业务逻辑里面加上跳转过程）。
   而且对于一个已经在线使用系统来说维护通常都是定期的，不是你改了个东西就要重启服务的，服务器也不会允许你频繁停启的。二、当页面表单需要自动变化或者频繁变化时。
  如果项目已经处于用户接收性测试的阶段应该不会存在页面表单频繁变化的情况。除非你处于开发阶段，需求分析做的不够细致，或者你的开发太XP了。
  而且页面表单通常我们可以用动态form来映射数据到业务逻辑层。后台的改动只会影响到前台jsp页面的改动。正要做到数据库一动页面跟着自动反映，好像还没有这种技术，即使是rubby on rails也只是在生成项目的时候可以直接从数据库generate，对于数据库的修改它也做不到这点。.net也不能。子要动动脚趾头想想，如果要实现，那么它必然可以在运行期根据数据库字段来自动生成前端页面，自动生成中间的数据超作，自动编译，就相当于存在一个另外的智能化的系统来自动即时地观察你的数据库结构还要即时地生成代码、编译代码，谁听说过有这种系统？我也希望有这种系统。三、要引入struts包，引入strtus标签库
   你期望的其实就是.net的webform的形式。可惜java不是.net。如果你实在是很希望用所见即所得，那么就去看看weblogic-workshop吧，但是如果你使用它，那么java得灵活性将大大损失。.net是越来越流行了，也说明代码民工越来越多了。不过要承认.net的工具的确是做的非常之精彩、非常之自动化。不过底层的原理基本和j2ee类似。JSF其实有些模范.net的嫌疑，不过技术都是相通的。

super_zzw 如果项目已经处于用户接收性测试的阶段应该不会存在页面表单频繁变化的情况。除非你处于开发阶段，需求分析做的不够细致，或者你的开发太XP了。
》》举个最简单的例子，人员基本信息指标是由客户自己管理的，比如系统里面有姓名、性别两个指标，哪天客户想添加一个“籍贯”的指标，他自己可以从系统后台来添加，同时，动态地直接在数据库中添加这个字段，同时，在输入页面自动生成相应的输入框，我只需要把系统里面这个表的相关字段提出来，生成相应的输入表单，这样的需求太正常了。而struts做不到。其他的，哎，不争论也罢。

哈,路过
楼主名字不错,有.net
还有邻家boy的头衔,狠有流行的breakBack味道,粉喜欢:P
java家发洋光大靠你了

楼主的问题并是struts带来的，而是你们的系统构架在开发前没有仔细考虑的问题，不能说struts不适合大系统。任何框架都不是万能，有长处也有短处。你们系统构架的错误不能说是struts错误像MIS或着ERP这样的系统开发，系统功能本来就要实现的很灵活，对于太灵活的系统个人感觉struts最好少使用，因为这样的系统数据库可能初始就几张表而已，其它的表可能都是用户在使用时自动生成的，页面也有很多是自动生成的，并且可能根据不同的情况，会发生变化。这样的情况下用struts还没javabean+jsp来的快。

super_zzw(之支吾) 你太面了，估计你根本就没有做过大的crm，erp，mis 以及工作流之类的问题。你做过才知道，东西都是定义在数据库里的，只要更新数据库，页面自己就变，根本就不用什么自己再去开发页面的！！！！

<<<页面的表单如果我需要动态生成，同时把系统的跳转路径都存到数据库里面，struts根本无法做到啊！
  晕,为什么要把路径存到数据库里？不要老想着这条路走不通，其它的路就不行了。比如：你做一个空白的jsp页面.
  里面什么都没有，jsp页面的内容是通过系统产生的。这时候路径不就固定了？  <<<看来，真正在使用struts的人才能发现struts的不足啊。
  晕，不得不让我来批你一下。我记得你在其它的版面发过，struts 的taglib很烦，不知道你有没有看过struts的源代码,
  它的每个标签是怎么实现的？还有，有的朋友说，taglib用起来巨不爽,经常出这样的或那样的莫名期秒的错误.
  造成这些《只有一个原因，它们对struts只是只处于刚开始的入门阶段.
    我自已看过struts1.0,struts1.1的源代码,用它们也有3，4年吧.我是做erp的，页面
  的复杂性也不差.还没有发现struts不能解决的问题。所以说，是你们的思路太窄，应该从多个方面的想问题。

调试易

struts带来的巨大烦恼…是不是系统做大了都不能使用struts?

解决方案 »