Live in code

其实这个问题一句话就可以讲清楚：过滤器气垫的顺序要有规则的！

在 Struts2 （或者 WebWork ）这个展现层框架的配置中，我们使用的前端控制器也是使用 Filter 这种方式管理的。一样是在 web.xml 中配置 Filter 的属性，但是由于我们需要由 Spring 托管整个 web 项目的东西，就拿我们这个 OpenSessionInView 的主角 Session 来说吧，如果这个 Session 是由 Spring 在整个程序运行过程中全权负责的话，它啥时候建立，啥时候消亡是 Spring 说的算的，固然必须由 Spring 先建立好在负责发配个对应的适用对象。啥时候建立呢？当时是当请求来的时候咯，当然得让 Spring 先知道吧！所以啊，这个 Spring 的 OpenSessionInViewFilter 的过滤器必须在 Struts2 的 FilterDispatcher 过滤器前配置。

部分代码大致如下：

<!-- Spring的OpenSessionInView实现 -->
<filter>
	<filter-name>openSessionInViewFilter</filter-name>
	<filter-class>
		org.springframework.orm.hibernate3.support.OpenSessionInViewFilter
	</filter-class>
</filter>
<filter-mapping>
	<filter-name>openSessionInViewFilter</filter-name>
	<url-pattern>/*</url-pattern>
</filter-mapping>

<!-- 添加 Struts2 过滤器 -->
<filter>
	<filter-name>struts2</filter-name>
	<filter-class>
		org.apache.struts2.dispatcher.FilterDispatcher
	</filter-class>
</filter>
<filter-mapping>
	<filter-name>struts2</filter-name>
	<url-pattern>/*</url-pattern>
</filter-mapping>

这样，Spring 的过滤器就可以先于 Struts2 的过滤器得知请求的到来，提前做好开启 Session 转载 bean 的各项准备任务。

所谓 OpenSessionInView 就是真对 Hibernate 这个数据持久层框架的一个Web下的使用技巧。我们在日常 MVC 程序开发的过程中，如果使用的是 Hibernate 的数据持久层框架，一定常常在业务逻辑层中出现 Session is closed 的 laze 异常，这是由于 Hibernate 的Session 在上一个操作中我们为了保证 Session 已经及时的回收时被我们关掉了。

我们常常被放在一个很尴尬的地带：我们的 DAO 成负责 CRUD 在执行完成后根据我上面说的那个“好习惯”，肯定要把本次操作的Session关掉，或者说在一个点统一被关掉。那么导致的结果是，当我拿到我们需要的对象时，该对象虽然说是数据完整的，但是他可能有一个 Link 对象，这个对象可是不完整的！顶多是一个包含 ID 的空壳。那很自然的，当我们要访问这个对象中的 Link 对象的某个非ID值的时候，必然抛出“Laze”异常。如果我们之前不关闭那个 Session 似乎一般的解决方案没法告诉在下一个使用层的代码何时关闭，虽然可以成功访问 Link 对象，但是长此以往 Session 就大大占用内存了。

如何设计才好呢？在很多 Hibernate 的使用者中就有人很早地提出了 Open Session In View 这个Web开发的重要理念，即让 Hibernate 的 Session 在整个请求周期中生存（包括建立和消亡）。当然这个是理念，实现手段有很多种了，包括什么参数传递、建立辅助包等等等等。这里我们专门提及 Spring 这个万能的整合型框架是如何处理的。

Spring 为我们提供了一个叫做 OpenSessionInViewFilter 的过滤器，他是标准的 Servlet Filter 所以我们把它按照规范配置到 web.xml 中方可使用。使用中我们必须配合使用 Spring 的 HibernateDaoSupport 来进行开发，也就是说，我们的dao层的类都要继承于 HibernateDaoSupport，从中由 Spring 来控制 Hibernate 的 Session 在请求来的时候开启，走的时候关闭，保证了我们访问数据对象时的稳定性。

下面我大概描述一下使用的方法：

1. 在 web.xml 中加入对应过滤器配置文件

<!-- Spring的OpenSessionInView实现 -->
<filter>
	<filter-name>openSessionInViewFilter</filter-name>
	<filter-class>
		org.springframework.orm.hibernate3.support.OpenSessionInViewFilter
	</filter-class>
</filter>
<filter-mapping>
	<filter-name>openSessionInViewFilter</filter-name>
	<url-pattern>/*</url-pattern>
</filter-mapping>

2. 在我们访问持久层数据是使用 Spring 为我们的 HibernateDaoSupport 的支持，并使用其中的对应方法操作我们的持久层数据

import org.springframework.orm.hibernate3.support.HibernateDaoSupport;

public class XxxDAO extends HibernateDaoSupport {

	public void save(Xxx transientInstance) {
		try {
			getHibernateTemplate().save(transientInstance);
		} catch (RuntimeException re) {
			throw re;
		}
	}

	public void delete(Xxx persistentInstance) {
		try {
			getHibernateTemplate().delete(persistentInstance);
		} catch (RuntimeException re) {
			throw re;
		}
	}

	public Xxx findById(Integer id) {
		try {
			Role instance = (Xxx) getHibernateTemplate().get("Xxx", id);
			return instance;
		} catch (RuntimeException re) {
			throw re;
		}
	}

	public List findByProperty(String propertyName, Object value) {
		try {
			String queryString = "from Xxx as model where model."
					+ propertyName + "= ?";
			return getHibernateTemplate().find(queryString, value);
		} catch (RuntimeException re) {
			throw re;
		}
	}
}

其实啊，就是调用 HibernateDaoSupport 中的 getHibernateTemplate() 这个模板方法，再使用里头的对应对持久层操作的方法。

这样，Spring 这个优秀的整合型框架就是轻松地帮我们把烦恼已久的问题解决了。

连续写了两次AOP的文章，总是觉得没有吧AOP说得很清楚。而且网络上每一篇AOP的教程都是充斥着大量专业术语，令人甚是费解。打算把各个术语根据spring这个aop的实现来串讲一边。

还是从“日志记录说起吧”，几乎我们所有的程序中都需要记录日志的，这是一个共通的需求。

如果我们要把日志记录提取出来，作为一个抽象的独立的服务我们可以叫它为 Advice （“通知”，说白了，advice就是一个功能逻辑）。

然后我们将这个“功能逻辑 ”-advice 加入到我们需要的地方，而这个地方就是我们所谓的 PointCut ，（“切入点”，我们使用中最常看到的就无非是：方法前、方法后、出异常时等等）。

重复上一篇文章的话：我们的 Aspect = Advice + PointCut 这样我们就形成了我们AOP最为基础“切面”

那么我们要把这个 advice 加在哪里呢？也就是说这个PointCut在哪里呢？这个就是我们所谓的 Target （“目标对象”）。我们的目标说白了也就是目标对象中的某些需要我们这个日志服务的方法罢了。

OK，我们有了我们的“通知”、“切入点”，也有了我们的“目标对象”，那么将“通知”加入到“目标对象”的“切入点”的动作就叫 weaving （“织入”）。呵呵，这个当然是有spring容器在运行时执行的咯，但是多我们来说就是在applicationContext.xml中加入对应的配置段咯。

这里，还有一个名词 Proxy （“代理对象”），如何理解这个词呢？它在实际使用中又是什么呢？我为此特别画了一张图：

所谓 Proxy 这个代理，说白了，在 Spring 的 AOP 应用中，就是将你那些需要插入服务的目标对象在一个新的、模拟好你这些目标对象的现有方法接口的一个新的对象。正如我画的这个图所示，其实在程序运行过程中我们使用的比不是我们自己设计出来的那个“DiyBean”，而是由 Spring 容器自动生成的一个对象“DiyBeanProxy”。我们调用的那些被声明配置过的方法时，也不是用我们对象默认的方法，而是根据配置的不同，重新生成的代理对象中的对应方法。就比如我们这图中的“methodTwo()”方法，代理对象中的(1)、(2)方法段其实就是对应着的就是切入点的功能啦，(1)就是等于“beforeMethod”，(2)就是相应的“afterMethod”了（当然还有在抛出异常的时候的服务我没有画出）。

综合来说，AOP不是什么特新的思想，就是我们一切业内的术语过于专业、抽象。不就是一个拦截，一个重新打包的过程嘛！不难！

近日一直沉醉在 O'REILLY 的群书中，记了不少学习笔记，受益匪浅。在看《Spring程序高手秘籍》中看到了译者注释的一段话，很好的（至少比我自己解释的好）。

他是这么说地：

AOP：即为aspect面向程序设计，是 OOP 的一种的补充或改进。

将 OOP 应用到现实世界时，时常发现系统中的各类会有许多共同使用的逻辑或责任（例如日志管理、权限控制、调度处理等） ，这些 “服务” 不断重复地 “切入” 各类中。

如果功能流程是纵向的，这些切入点就是所谓的 point-cut，而在此提供服务的额外程序代码就是所谓的 advice。简而言之，point-cut 与 advice 的组合就成为的 aspect，就是这些共同使用的逻辑或责任的封装。

通过 AOP 可将程序的责任理清，对象与 aspect 互不干扰。另外，aspect 的模组并非显示地为对象所用，而是通过依赖注入或拦截方式获得被封装在对象内部的方法与信息。

好久都没有这股劲了，好久也没有在家里这样的时间了。于是昨天提出的Blog模板制造计划今天就结束了！对于这个模板来说主要是为了衬托这个主要记录我代码历程的博客，我为他起名为《coding-life》

同时也感谢creativebits提供了比较好的css素材。

近期由于空间的稳定，我逐渐开始使用wordpress了，目前都是使用别人的模板，或多或少的都有点遗憾！要么不支持我必备的plugins，要么就是显示不正常~~~

所以我决定自己写一个适用的模板，不就是php嘛！小case！