|
在上一篇文章里说到，我们对UserManagerImpl类所有的方法进行了spring事物控制，而UserManagerImpl实现了UserManager接口，也许有人会说我的业务逻辑又不经常改变，为何还要多写这么一个接口，这不是很麻烦，接口的目的就是为了以后扩充业务逻辑而准备的，单改变业务逻辑的时候我重新实现一下这个接口，而不必要去动原有的实现类，而前期我业务逻辑很简单，不会变化，为了达到敏捷编程，前期设计我想尽量保持简单，这样不好吗？确实，前期尽量简单后期再进行重构，思想是不错，但由于spring的事物管理机制要么是基于AOP，或者CGLIB，要么是aspectJ，但这些技术都是基于代理技术实现，也就是说他们会拿其中某个类做为代理，然后返回一个代理对象，而当你的具有容器托管的业务逻辑类在没有接口的情况下，spring会把具体的实现类做为代理来实现事物管理，在这种情况下，当你在客户端代码里用:
UserManager userManager = (UserManager)ServiceLocator.getService("userManager");的时候会报java.lang.ClassCastException错误，因为这样得到对象不是UserManager的实现，而是spring返回一个形如：$Proxy这样的代理对象，所以你就不能对它进行操作，怎么办，无奈，你别无选择，你只能为UserManagerImpl类建立一个接口，然后实现这个接口，那么spring就会用UserManager这个接口来做为代理，而不是UserManagerImpl来做为代理了，所以这就是为什么有事物控制时一定要有接口的原因！
其时在hibernate里，如果要用spring的基于aspectJ的AOP技术来进行事物控制的话，你的pojo对象最好不要有基类，也就是说最好不要有以下的形式出现POJO类：
public class User extends Entity {
}
如果是这样的话，加载spring上下文的时候会出现Entity类找不到的情况，具体是什么原因，还在分析中，所以当你在基类的POJO对象时，最好不要用基于aspectJ的AOP技术来实现事物管理！ |
|
|
