最近在梳理整个web中的一些元素，希望能够做一些删减和调整。看看一些元素的使用是否合理。
web文件中的加载顺序：context-param –> listener -> filter(按照出现的顺序) -> servlet(按照出现的顺序)
先看看listener。
listener大致上有： ServletContextListener，ServletContextAttributeListener，ServletRequestAttributeListener，ServletRequestListener。前两者是负责整个上下文的监听，web启动或是属性改变。所以这类监听器很适合那些只需要加载一次的配置，例如log4j、Spring的配置上下文等等一次性的工作。
至于HttpSessionAttributeListener，主流的做法对于会话的保存不会在服务端的内存中，故这个监听器也就不常出场了。
ServletRequestListener是针对一个请求的监听，里面两个方法：requestDestroyed、requestInitialized 请求的初始化和销毁。这个的功能和filter有些类似，但是未被大量使用的缘由在于针对的是单个请求，且是请求生命周期的开始和结束，并没有处在请求链中，使用场景有一定的局限性。
所以在web开发的监听器中，出场最多的是ServletContextListener.
案例： org.springframework.web.util.Log4jConfigListener ，org.springframework.web.context.ContextLoaderListener
再看filter，故名思议就是一个过滤器，当初的定义就是处理每一个请求(每一个请求都是新的),这个工作可能是主动的，也可能是被动的，同时拥有请求中断的权利。所以一些web处理框架都是基于filter做控制，而且对于非业务性的工作也大多通过filter来处理。
典型的struts2的初始化、分发调度(StrutsPrepareFilter，StrutsExecuteFilter)、权限判断、字符编码(CharacterEncodingFilter)等工作.更偏非业务的工作。
最后是servlet，它的出现是承载原来jsp中业务逻辑部分的工作，放到了服务端，也是最早期是jsp + servlet + javabean的MVC model 1 模式(后来出现的都是model 2的MVC)，更多的是一些业务逻辑的封装，struts1中的action就是基于servlet，到后来为了解耦，使得普通的POJO也可以使用，所以剥离了servlet API，这个是后话，处于其他方面的考虑而已。总体上来说，偏业务的逻辑会放到servlet中。说到这里就出现了一个让人很苦恼的问题，springmvc采用的是servlet做入口控制器：DispatcherServlet 不知道是处于什么目的，真的很打脸啊！后来去看了下tapestry、Turbine也都是通过servlet做控制器。
struts从1的servlet到filter是因为servlet是线程非安全的，所以采用了filter，后端业务action多实例的方式.springmvc的规则映射是在servlet持有，因为这些东西是需要被长期持有的，而对于这些东西spring采用的处理方式：不将这部分逻辑分发到其他类中处理(struts2中是交给PrepareOperations和ExecuteOperations)。可能从spring的角度来看，路由查找匹配是框架自身的业务，所以通过了servlet来实现。tapestry、Turbine等框架的实现也大致验证了这点，所以是否可以认为struts2的入口设置有问题呢？虽然通过两个filter来做了功能点的分离，便于在准备和调度时可以插入一些其他的操作，但是是否可以通过其他方式来实现呢？无法定论。
0 条评论。