一、 它太过于依赖web容器,当配置文件改动一次就要重新启动
转到展示层时,需要配置forward,每一次转到展示层,相信大多数都是直接转到jsp,而涉及到转向,需要配置forward,如果有十个展示层的jsp,需要配置十次struts,而且还不包括有时候目录、文件变更,需要重新修改forward,注意,每次修改配置之后,要求重新部署整个项目,而tomcat这样的服务器,还必须重新启动服务器,如果业务变更复杂频繁的系统,这样的操作简单不可想象。
二、 Struts 的Action必需是thread-safe方式,它仅仅允许一个实例去处理所有的请求。所以action用到的所有的资源都必需统一同步,这个就引起了线程安全的问题。
三、 测试不方便.
Struts的每个Action都同Web层耦合在一起,这样它的测试依赖于Web容器,单元测试也很难实现。不过有一个Junit的扩展工具 Struts TestCase可以实现它的单元测试。
四、 类型的转换.
Struts的FormBean把所有的数据都作为String类型,它可以使用工具Commons-Beanutils进行类型转化。但它的转化都是在Class级别,而且转化的类型是不可配置的。类型转化时的错误信息返回给用户也是非常困难的。
五、 对Servlet的依赖性过强.
Struts处理Action时必需要依赖ServletRequest 和ServletResponse,所以它摆脱不了Servlet容器,测试也比较困难。
六、 支持的表现层技术单一
Struts 1只支持JSP作为表现层技术,不提供与其他表现层技术,例如Velocity、FreeMarker等技术的整合。
前端表达式语言方面.Struts集成了JSTL,所以它主要使用JSTL的表达式语言来获取数据。可是JSTL的表达式语言在Collection和索引属性方面处理显得很弱。
七、 对Action执行的控制困难.
Struts创建一个Action,如果想控制它的执行顺序将会非常困难。甚至你要重新去写Servlet来实现你的这个功能需求。
八、 对Action 执行前和后的处理.
Struts处理Action的时候是基于class的hierarchies(层次结构),很难在action处理前和后进行操作。
九、 对事件支持不够.
在struts中,实际是一个表单Form对应一个Action类(或DispatchAction),换一句话说:在Struts中实际是一个表单只能对应一个事件,struts这种事件方式称为application event,application event和component event相比是一种粗粒度的事件。