讨论：框架这样用？

问题太多了，简直就是Bad Practice的集合啊......

通过楼主的描述我感到很迷惑：“同名的jsp往往主要内容相同，只是form要提交到的action不同”，用目录来管理jsp页面还是很常见的，但是这第二条就很奇怪，如果只是简单的action不同，完全可以在页面里用parameter标示，或者用Javascript控制提交。相同的内容保存在不同的地方本身就是大忌，这样很容易造成内容不同步……
关于你们action的写法，刚才查了一下，一个action后面有6个forward。如果将一个action作为一组业务的前期处理和分发使用（其实我们也不推荐这样做），这样做是可以理解的。但所有的forward都指向了页面，这就说明这个action还要处理逻辑。设想一下，一个有六个forward的action正常来讲需要6个if 语句来判断，这就是12行代码，你这个方法得多大啊，一片一片的代码……。

这样其实就说明了一个问题，系统对业务实现的规划实在是太差了，而且恐怕没有完整、强有力的标准。在使用框架时，我感觉内部统一的使用标准是最关键因素。不过注意的是，这个使用标准并不是使用习惯。

“使用了LazyValidatorForm，所有的form都使用这一个东东，直接将数据映射到hibernate持久化对象去了”。
这是个恐怖的做法，我们曾经也是深受其害。第一个问题：你这样做直接将表示出拉到了Hibernate所在的持久层。LazyValidatorForm里面携带的东西是危险的！还有个问题是你这样抹杀了业务层，充分说明你分层是有问题的。你说的那个几百行代码的问题其实多写个工具库或者直接用BeanUtil的拷贝就能解决问题。还有一些更优的解决方案。。。

就事论事，就先说到这里。

这个回复好长啊，都有“Bad Smell”了，

楼上的兄弟，能不能提供一些更优的解决方案？
我不怕重构，就想多学习一些框架的使用技巧和设计思想。
你做过这方面的项目，能细讲一下
struts+hibernate+spring的work flow 吗？
万分感谢。。

看了下，问题多在流转上，因为structs的控制和流程在一起，这个问题没有办法解决，即便解决了就像Spring Web Flow那样处理。或者你采用spring web flow来处理，唯一的缺点吧，就是要写一堆的webflow.xml了，但目前的页面或者代码就不用动太多!

个人感觉 Spring，struts，hibernate
都是些复杂的东西，原本很简单的事，为什么要做的如此复杂？

难道用了一个xml配置文件就mvc，就面向对象？

即便是一个简单的功能，用了这些框架，文件数爆涨。
如果要进行一个改动，需要同时涉及好几个文件，
这样的代码难道好维护？

下定决心重构吧,
60个JSP的项目不算大,现在重构花的代价还比较小

就算是配置文件，也比zero configuration强。。

全部都按照约定来匹配， 大点团队加上良莠不齐的队员，根本没法做

解决方法多了，不过，我个人觉得，反正都是要改，不如多花点时间好好重构一下，这样以后维护和扩展起来也不较容易。
再者，实在不想重构，就在进入每个页面是加一个标记参数，这样比较容易定位页面，也有些工作量的。

这样做的好处是可以减少很多类，减少很多配制文件。
其实有点STRUTS2的味道啦，建议改改  ACTION 的基类，利用反射去动态调用参数method标明的方法
小项目用这个开发速度超快的~

ibatis 的 petstore 整个项目只用了一个ACTION，还不是自己写的~

一个CURD需要 4个ACTION，1个FORM，1个DAO接口，1个DAO实现，1个SERVICE接口，1个SERVICE实现 。。。 这样的设计就是好的设计吗？翻翻我们项目里面上千个ACTION，十几个ACTION CONFIG 你就知道我们有多痛苦。。。。

楼上的苦衷我深有感触，开发的时候还好说，无非多实现几个接口，维护的时候可真够郁闷的了，一层一层的扒拉着找，烦都烦透了。我们追求的不是高效简洁的开发方式么？这就是这些框架给我们带来的效率？