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