程序链接的好处 程序开发过程中Struts为您带来怎样的好处

程序开发过程中Struts为您带来怎样的好处  

　　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的自定义Servlet ActionServlet在拦截过程中注入了一个ActionForm对象和一个ActionMapping对象 经过这个过程后 Struts为开发者带来了如下实际的好处 通过ActionMapping Action在转发时 并不是转发给一个实际的页面 而是转发给在strus config xml中已经配置的对象 这意味着 在不改变Action代码的情况下就可以更换其转发的页面;如果没有ActionMapping 当有 个Action都要更换转发页面时 我们不得不在庞大的Web应用中找出这 个Action 修改其转发页面 然后再重新编译它们 有了ActionMapping后 只需要在struts config xml中修改相应的配置即可 这样既查找方便 又不用重新编译

　　现在的一个主要问题是 Web应用一旦投入使用之后 更换转发页面的可能性有多大?Action转发的页面 一般都是直接向用户展示的JSP页面 软件工程中 一切和用户直接打交道的部分都是极易发生变化的

　　当然Struts肯定还有其它方面的便利之处 但是这些还并不足以打动我去使用Struts 即便它还提供了丰富的标签库

　　最终一个重要的原因让我认为我的确需要采用像Struts这样的框架 当然 首先我一直是相信MVC模型所倡导的理念的 将视图和模型分开 把和用户交互的部分独立出来的好处是明显的

　　首先如前面所述 和用户交互的部分是最易发生变化的 视图的独立意味着变化的隔离;然后是将视图分离出去后 开发者可以将精力集中在对业务流程的处理上 一个大型的系统 最复杂的最核心的部分就是处理业务流程 可是实际的情况是 繁琐地界面处理占用了程序员大量甚至是大部分的时间

　　我相信了MVC模型带来的好处 所以开发Web应用时我一定会采用这种模式 但是我并不需要Struts 因为Servlet就可以让我实现MVC模型 我的这种想法似乎很自然 但是这里面隐含着一个前提是 我每次开发Web应用 都必须有意识的严格按照MVC规范来写 这看起来不是很困难 但是做起来却很难 因为有时候在业务处理过程中嵌入几行关于界面的代码似乎是非常自然而且简单的 于是我就真的这样做了 一段时间之后 我突然发现我的业务处理过程和界面显示部分又混杂在一起了 至此我才真正相信我要使用Struts