Struts的巨大烦恼 真的不适合大系统？
来源：网络 更新时间：2014-11-27
经过一段时间使用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的技术结构。
