议论：框架这样用

讨论：框架这样用？

??

这就会出现一个潜在的问题：netinfoAction类中不同的处理函数会随着业务的不断细化而迅速增加，不说代码量大，无法迅速定位到要修改的函数处（那时用搜索都慢），单说各个函数之间相互跳转并最终返回到指定页面：函数之间怎么能跳转？看上面的代码：Action返回success时，就会定位到manager方法继续执行，manager 方法还有可能再定位到这个类的其他方法继续执行，最后，很难控制我最初的方法返回的页面究竟是哪个，并且要考虑到另一个页面调用同类的manager方法时，是立即返回一个页面还是要推给另一个方法来定位最终页面。当业务多了，这个问题相当突出，而大量的精力将用在如何正确定位返回页面了。

2、使用了LazyValidatorForm，所有的form都使用这一个东东，直接将数据映射到hibernate持久化对象去了, 但这样的映射不能变通，只能在将要映射前把数据的格式转化一下，再做映射，无疑又增加了几百行代码。

3、由于页面中有URL或连接，每个连接要调用一个ACTION的处理函数，就得写成这样.../neitinfo.dox?method=方法名，这种连接返回的页面往往和form提交到的ACTION方法有不一样的返回页面，甚至还要返回到本页面，前面说过，本页面和另一个页面同名并且也有相同的连接，这就出现问题了，当这些页面的连接都要调用一个处理类的同一个方法时，就不得不使用flag之类的东西来标示是哪个页面来的请求，要回到哪个页面去。。地狱。。

虽然可以在函数中写上下面的文字来解决返回的问题，但还是感觉乱乱的，不舒服：


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

12 楼 yimlin 2007-07-31   看了下，问题多在流转上，因为structs的控制和流程在一起，这个问题没有办法解决，即便解决了就像Spring Web Flow那样处理。或者你采用spring web flow来处理，唯一的缺点吧，就是要写一堆的webflow.xml了，但目前的页面或者代码就不用动太多! 13 楼 local 2007-08-09   个人感觉 Spring，struts，hibernate
都是些复杂的东西，原本很简单的事，为什么要做的如此复杂？

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

即便是一个简单的功能，用了这些框架，文件数爆涨。
如果要进行一个改动，需要同时涉及好几个文件，
这样的代码难道好维护？ 14 楼 wang20051 2007-08-09   下定决心重构吧,
60个JSP的项目不算大,现在重构花的代价还比较小 15 楼 realdah 2007-08-10   就算是配置文件，也比zero configuration强。。

全部都按照约定来匹配， 大点团队加上良莠不齐的队员，根本没法做 16 楼 ss19811029 2007-08-10   解决方法多了，不过，我个人觉得，反正都是要改，不如多花点时间好好重构一下，这样以后维护和扩展起来也不较容易。
再者，实在不想重构，就在进入每个页面是加一个标记参数，这样比较容易定位页面，也有些工作量的。 17 楼 flashroom 2007-08-22   这样做的好处是可以减少很多类，减少很多配制文件。
其实有点STRUTS2的味道啦，建议改改  ACTION 的基类，利用反射去动态调用参数method标明的方法
小项目用这个开发速度超快的~ 18 楼 flashroom 2007-08-22   ibatis 的 petstore 整个项目只用了一个ACTION，还不是自己写的~

一个CURD需要 4个ACTION，1个FORM，1个DAO接口，1个DAO实现，1个SERVICE接口，1个SERVICE实现 。。。 这样的设计就是好的设计吗？翻翻我们项目里面上千个ACTION，十几个ACTION CONFIG 你就知道我们有多痛苦。。。。
19 楼 flash 2007-12-26   楼上的苦衷我深有感触，开发的时候还好说，无非多实现几个接口，维护的时候可真够郁闷的了，一层一层的扒拉着找，烦都烦透了。我们追求的不是高效简洁的开发方式么？这就是这些框架给我们带来的效率？