讨论：框架这样用？

flash59

浏览: 97752 次
性别:
来自: 北京

最近访客更多访客>>

u012363178

wangyy

bigguo

luokery

博主相关

博客

微博

相册

留言

关于我

文章分类

社区版块

存档分类

博客分类：

项目学习

框架 JSP Spring Hibernate Struts

现在接手的项目是个别人已经搭好了架子的东东，在后来一段时间的开发过程中，我发现这个系统有一些缺点，总结了一下：

一、表示层

1、第一次看到，把同名的jsp放在不同的目录下，用目录名来区分。

2、同名的jsp往往主要内容相同，只是form要提交到的action不同。

二、控制层（逻辑处理层）

1、本项目大约有20个jsp页面，只用了5个ACTION，每个页面指向某个ACTION的某个处理方法：

比方说：jsp1的form这样写：

<html:form action="/netinfo.dox" method="post" focus="domain" styleClass="form" >
<input type="hidden" name="method" value="save"/>

有一个隐藏变量method来标示要由netinfo的save方法来处理，那看一下struts-config.xml里是怎么写的：

struts-config.xml 代码

<form-beans>
<form-bean name="NetinfoForm"
type="org.apache.struts.validator.LazyValidatorForm" />
.....
form-beans>
<action-mappings>
<action path="/netinfo" name="NetinfoForm" parameter="method"
scope="request" validate="false">
<forward name="list" path="/pages/netinfoManager.jsp" />
<forward name="view" path="/pages/netinfoView.jsp" />
<forward name="regester" path="/pages/registerNetinfo.jsp" />
<forward name="edit" path="/pages/Manager/registerNetinfo.jsp" />
<forward name="password" path="/pages/getBackPwd.jsp" />
<forward name="success" path="/netinfo.dox?method=manager" />
action>
.......
<action-mappings>

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

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

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

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

jsp代码

<html:hidden property="source" value=""

java 代码

//返回本页
return new ActionForward(request.getParameter("sourcepage"));

对于这些问题，不知道应不应该换一种组织形式，重新架构。

仔细考虑了一下，结合朋友们的意见，我最终决定把ACTION的数目加上来，这样每个ACTION的函数就可以少一点，不至于那么乱，还有，关于JSP的名称，我决定要改，两个文件同名，在IDE中同时打开这两个文件，将不知道正在修改的页面是哪个，容易产生错误。

好像，增加ACTION的个数就可以解决以上大部分问题了。

希望大家说说自己的意见。

分享到：

char,varchar,text,nchar,nvarchar,ntext的 ... | 开篇：在项目中学习和锻炼，摸索前进......

2007-07-26 09:44
浏览 5386
评论(19)
论坛回复 / 浏览 (19 / 10731)
分类:企业架构
查看更多

19 楼 flash 2007-12-26

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

18 楼 flashroom 2007-08-22

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

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

17 楼 flashroom 2007-08-22

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

16 楼 ss19811029 2007-08-10

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

15 楼 realdah 2007-08-10

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

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

14 楼 wang20051 2007-08-09

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

13 楼 local 2007-08-09

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

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

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

12 楼 yimlin 2007-07-31

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

11 楼 flash59 2007-07-31

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

10 楼 Garriot 2007-07-30

问题太多了，简直就是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”了，

9 楼 huangpengxiao 2007-07-30

netinfo 很熟的名字……

持续封装持续集成

8 楼 guoliang0571 2007-07-28

wl95421 写道

个人观点,仅供参考:
配置文件过多，不是好事
如果配置文件没有好的UI工具进行管理
还不如用IDE写代码

一个大系统中，如果采用Spring-Struts-Hibernate架构
就会发现，一个功能往往涉及多个配置文件，查找起来
一个字，烦!

很支持你啊，我还是喜欢ＥＪＢ３，
　用spring 配置文件真是多啊，而且一个不行，影响整个运行．
　ＰＳ：
spring　里一个service没set好项目就起不来了，（我不想用懒加载，就想启动加载不可以吗）
　找起来也麻烦，还要找响应的开发人员哦，感觉EJB3这方便好多了．　
　好希望ＥＪＢ３流行起来啊．．．．．．．
　

7 楼 guyuanwuxin 2007-07-27

一用DispathAction没有问题，目前是Action的粒度有些大，根据你的业务重新组织Action的粒度
二仿照ROR RHTML的方式把共同表示逻辑的JSP变成类似于模板的方式，至于关于JSP目录方式个人认为没有什么问题。

6 楼 flash59 2007-07-27

呵呵，20个页面是个虚数，回去查了一下，60多个jsp！

如果20个，我也就将就了，60个，就很难忍受了。。。

5 楼 dennis_zane 2007-07-27

20个JSP的项目？那应该是规模很小的项目了
表示层通过目录来划分模块，同名JSP很正常的，通常都是list,edit,add等，有的人喜欢添加个后缀名（模块名），有的人就不添加，通过目录名来区分不会带来什么问题的。

5个action少了点，很容易出现magic action，action变的庞大，最好是根据功能项划分action为妙，这个要重构了。

LazyValidatorForm的使用，那就是仁者见仁，智者见智了。

4 楼 galaxystar 2007-07-27

web层确实应该做到 zero configuration

3 楼 wl95421 2007-07-26

2 楼 bluepopopo 2007-07-26

应该是DispatchAction过度使用了吧可能前期没有预计aciton逻辑
不用flag来标识同名页面调用的话 action还是费点事增加方法虽然还是调用原先的方法

1 楼 liusong1220 2007-07-26

下个决心，重新架构吧

发表评论

您还没有登录,请您登录后再发表评论

最近访客更多访客>>

博主相关

文章分类

社区版块

存档分类

最新评论