框架原理小结.docVIP

框架原理小结 一、框架原理简介 在学习Struts2框架原理以后，我们了解到Struts2并不是一个陌生的框架，它是以Webwork的设计思想为核心，吸收Struts1的优点可以说Struts2是Webwork和Struts1的产物。 struts2 的工作原理图： 一个请求在Struts2框架中分为以下几个步骤： 1. 客户端发出一个指向servlet容器的请求 tomcat ； 2. 这个请求会经过图中的几个过滤器，最后会到达FilterDispatcher过滤器。 3. 过滤器FilterDispatcher是struts2框架的心脏，在处理用户请求时，它和请求一起相互配合访问struts2?的底层框架结构。在web容器启动时，struts2框架会自动加载配置文件里相关参数，并转换成相应的类。 4. 如果找到需要调用的Action，过滤器会把请求的处理交给ActionProxy。ActionProxy为Action的代理对象?。ActionProxy通过ConfigurationManager询问框架的配置文件，找到需要调用的Action类。 5. ActionProxy创建一个ActionInvocation的实例。ActionInvocation在ActionProxy层之下，它表示了Action的执行状态,或者说它控制的Action的执行步骤。它持有Action实例和所有的Interceptor。 6. ActionInvocation实例使用命名模式来调用，1. ActionInvocation初始化时，根据配置，加载Action相关的所有Interceptor。2. 通过ActionInvocation.invoke方法调用Action实现时，执行Interceptor。在调用Action的过程前后，涉及到相关拦截器 intercepetor 的调用。 7. 一旦Action执行完毕，ActionInvocation负责根据struts.xml中的配置找到对应的返回结果。返回结果通常是（但不总是，也可能是另外的一个Action链）一个需要被表示的JSP或者FreeMarker的模版。在表示的过程中可以使用Struts2 框架中继承的标签。 Struts2的特点： struts2核心控制器：FilterDispatcherStruts 2用于处理用户请求的Action实例，并不是用户实现的业务控制器，而是Action代理——因为用户实现的业务控制器并没有与Servlet API耦合，显然无法处理用户请求。而Struts 2框架提供了系列拦截器，该系列拦截器负责将HttpServletRequest请求中的请求参数解析出来，传入到Action中，并回调Action的execute方法来处理用户请求。显然，上面的处理过程是典型的AOP（面向切面编程）处理方式。 Struts2 Action有以下特点:—? Action类完全是一个POJO，因此具有很好的代码复用性。—? Action类无需与Servlet API耦合，因此进行单元测试非常简单。—? Action类的execute方法仅返回一个字符串作为处理结果，该处理结果可映射到任何的视图，甚至是另一个Action。 Struts2的配置文件有两份： —配置Action的struts.xml文件。 Struts1与Struts2的比较： 在Action实现类方面的对比：Struts1要求Action类继承一个抽象基类；Struts1的一个具体问题是使用抽象类编程而不是接口。Struts2Action类可以实现一个?Action接口，也可以实现其他接口，使可选和制定的服务成为可能。Struts2提供一个ActionSupport基类去实现常用的接口。即使Action接口不是必须实现的，只有一个包含execute的POJO类都可以用作Struts2的Action。 线程模式方面的对比：Struts1Action是单例模式并且必须是线程安全的，因为仅有Action的一个实例来处理所有的请求。单例策略限制了Struts 1 Action能做的事，并且要在开发时特别小心。Action资源必须是线程安全的或同步的；Struts 2 Action对象为每一个请求产生一个实例，因此没有线程安全问题。 Servlet依赖方面的对比：Struts 1 Action依赖于Servlet API，因为Struts 1 Action的execute方法中有HttpServletRequest和HttpServletResponse方法。Struts 2 Action不再依赖于Servlet API，从而允许Action脱离Web容器运行，从而降低了测试Acti