Struts是对MVC模型的实现于是许多讲解Struts的书用Servlet做了个符合MVC要求的Web应用再用Struts做了个同样功能的Web应用但是在对两种方式的对比中我发现Struts似乎并没有为开发者带来很大的方便以下是我的对比
视图两者一样
控制器利用Struts并不能完全摆脱这一层开发者还是需要写Action使用Servlet方式也是写一个同Action一样的Servlet充当控制器两者在代码量上没有区别在程序逻辑上也一样
模型两者一样
两者的主要差别Struts多了一个ActionServlet
既然编写一个类似Acition的Servlet就可以充当控制器那么Struts在提供Action后ActionServlet的意义何在？
ActionServlet的作用是拦截用户请求并将用户请求转发给合适的Action而自己的Web应用是将用户请求直接发送给功能等同于Action的自定义ServletActionServlet在拦截过程中注入了一个ActionForm对象和一个ActionMapping对象经过这个过程后Struts为开发者带来了如下实际的好处通过ActionMappingAction在转发时并不是转发给一个实际的页面而是转发给在strusconfigxml中已经配置的对象这意味着在不改变Action代码的情况下就可以更换其转发的页面如果没有ActionMapping当有个Action都要更换转发页面时我们不得不在庞大的Web应用中找出这个Action修改其转发页面然后再重新编译它们有了ActionMapping后只需要在strutsconfigxml中修改相应的配置即可这样既查找方便又不用重新编译
现在的一个主要问题是Web应用一旦投入使用之后更换转发页面的可能性有多大？Action转发的页面一般都是直接向用户展示的JSP页面软件工程中一切和用户直接打交道的部分都是极易发生变化的
当然Struts肯定还有其它方面的便利之处但是这些还并不足以打动我去使用Struts即便它还提供了丰富的标签库
最终一个重要的原因让我认为我的确需要采用像Struts这样的框架当然首先我一直是相信MVC模型所倡导的理念的将视图和模型分开把和用户交互的部分独立出来的好处是明显的
首先如前面所述和用户交互的部分是最易发生变化的视图的独立意味着变化的隔离然后是将视图分离出去后开发者可以将精力集中在对业务流程的处理上一个大型的系统最复杂的最核心的部分就是处理业务流程可是实际的情况是繁琐地界面处理占用了程序员大量甚至是大部分的时间
我相信了MVC模型带来的好处所以开发Web应用时我一定会采用这种模式但是我并不需要Struts因为Servlet就可以让我实现MVC模型我的这种想法似乎很自然但是这里面隐含着一个前提是我每次开发Web应用都必须有意识的严格按照MVC规范来写这看起来不是很困难但是做起来却很难因为有时候在业务处理过程中嵌入几行关于界面的代码似乎是非常自然而且简单的于是我就真的这样做了一段时间之后我突然发现我的业务处理过程和界面显示部分又混杂在一起了至此我才真正相信我要使用Struts
因为Struts可以规范程序员的行为也许Struts并不能降低实际的代码量甚至有时候不使用Struts的代码可能更简洁但是按照Struts写出来的Web应用却一定是符合MVC模型的就我认为这是采用Struts的最大好处规范程序员的行为让程序在不知不觉中写出符合优秀架构的代码这应该是所有框架的共同目的也应该是根本目的
