Servlet,Listener,Filter的一些思考

最近在梳理整个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来做了功能点的分离,便于在准备和调度时可以插入一些其他的操作,但是是否可以通过其他方式来实现呢?无法定论。

作者: inter12

在这苦短的人生中,追求点自己的简单快乐

发表评论

电子邮件地址不会被公开。 必填项已用*标注