Struts的巨大烦恼 真的不适合大系统？
在网上看到了一位仁兄的文章-"Struts的巨大烦恼 真的不适合大系统？ ",看了以后,不敢苟同这位仁兄的说法,于是把文章转过来,希望大家一起看看,看过之余希望有所思考。无论你觉得文中的观点正确与否，高兴的话，大家在评论中谈谈自己的观点～
原文如下：
经过一段时间使用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的技术结构
