关闭

Struts的巨大烦恼 真的不适合大系统?

636人阅读 评论(0) 收藏 举报
  经过一段时间使用struts,随着系统越做越大,现在,我终于要抛弃struts了,因为到现在,struts的巨大不足和缺陷越来越影响到我的项目的进度和开发效率了。

  背景:现在,我负责着一个大型企业的人力资源管理系统,整个系统管理的人员大约有1.6万人左右,系统基于jboss+oracle,java技术框架为struts,少许的报表用到了 servlet,项目开发的时间差不多一年,好,转入正题。

  到现在为止,我认为formbean 的好处就是和页面表单对应起来,在系统业务处理中,可以实例化formbean之就可以取出页面表单的值来,方便于在业务逻辑中引用。使得业务处理层和展示层可以分离开来,到现在为止,这也是我发现struts的唯一好处。

  但struts带给我的烦恼,各位,实在太多太多了,主要的几点我罗列如下:

  一、转到展示层时,需要配置forward,每一次转到展示层,相信大多数都是直接转到jsp,而涉及到转向,需要配置forward,如果有十个展示层的jsp,需要配置十次struts,而且还不包括有时候目录、文件变更,需要重新修改forward,注意,每次修改配置之后,要求重新部署整个项目,而tomcate这样的服务器,还必须重新启动服务器,如果业务变更复杂频繁的系统,这样的操作简单不可想象。现在就是这样,几十上百个人同时在线使用我们的 系统,大家可以想象一下,我的烦恼有多大。

  二、当页面表单需要自动变化或者频繁变化时。

  对于一个成熟的MIS系统来说,页面表单肯定是不固定的,甚至象有些系统,页面表单是存在数据库中,需要填写的表单在页面自动生成,比如填写一个人员基本信息,本来只需要填写 姓名、性别、出生年月 三个指标,而我后来需要增加籍贯这样的指标,我只需要在数据库中添加籍贯这个记录,并在页面就能自动增加籍贯这样的表单。而 struts在这方面,其优势反而变成了不足,我参考了非常多的人力资源管理系 统,这些系统几乎都能够做系统里面就可以控制人员信息的指示,进行使展示层能随之灵活变化,如果使用了struts,这些灵活性就根本用不上。

  同时,如果页面表单频繁变化时,就需要频繁修改formbean对应的方法和属性,而每次修改之后,就要求重新部署,或者重新启动服务器……。

  三、要引入struts包,引入strtus标签库,现到现为止,我们有所见即所得的dreamwaver、frontpage、webeditor,对于繁杂页面的设计,是非常方便的,而对于struts标签库,没有哪一种软件能够支持。jbuilder我没用过,不知道支持不支持,而为了维护这些标签库,增加工作量支持,也非常容易出错,稍微不小心,就一堆异常抛出来,系统他死给你看。

  总结:

  现在为什么asp.net越来越流行,非常重要的一点,就是asp.net这样的模式,简单,易于控制。而且我现在仍然觉得,利用jsp的文件名作为路径的映射非常方便,而struts还非常去配置action,使之有带有象.do、.main这样后缀的路径访问方式,不但增加了系统功能的复杂性,影响了系统的性能不说,还增加了非常多的系统不可掌握因素。其实 javabean+jsp,利用javabean处理业务逻辑,只利用jsp来展示数据,这正是.net的原型,同样,即可以不用去配置struts、也不需要象serlet一样去配置web.xml带来的麻烦。 所以,并不是所有的框架都是好的,越简单越易于控制。
 
  所以,现在,我决定放弃struts,转而采用javabean+jsp的技术结构
0
0

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:75547次
    • 积分:959
    • 等级:
    • 排名:千里之外
    • 原创:18篇
    • 转载:14篇
    • 译文:0篇
    • 评论:3条
    最新评论