ioc实现原理

转载至：http://jiwenke.iteye.com/blog/493965

IOC基础

下面我们从IOC/AOP开始，它们是Spring平台实现的核心部分；虽然，我们一开始大多只是在这个层面上，做一些配置和外部特性的使用工作，但对这两个核心模块工作原理和运作机制的理解，对深入理解Spring平台，却是至关重要的；因为，它们同时也是Spring其他模块实现的基础。从Spring要做到的目标，也就是从简化Java EE开发的出发点来看，简单的来说，它是通过对POJO开发的支持，来具体实现的；具体的说，Spring通过为应用开发提供基于POJO的开发模式，把应用开发和复杂的Java EE服务，实现解耦，并通过提高单元测试的覆盖率，从而有效的提高整个应用的开发质量。这样一来，实际上，就需要把为POJO提供支持的，各种Java EE服务支持抽象到应用平台中去，去封装起来；而这种封装功能的实现，在Spring中，就是由IOC容器以及AOP来具体提供的，这两个模块，在很大程度上，体现了Spring作为应用开发平台的核心价值。它们的实现，是Rod.Johnson在他的另一本著作《Expert One-on-One J2EE Development without EJB》 中，所提到Without EJB设计思想的体现；同时也深刻的体现了Spring背后的设计理念。

从更深一点的技术层面上来看，因为Spring是一个基于Java语言的应用平台，如果我们能够对Java计算模型，比如像JVM虚拟机实现技术的基本原理有一些了解，会让我们对Spring实现的理解，更加的深入，这些JVM虚拟机的特性使用，包括像反射机制，代理类，字节码技术等等。它们都是在Spring实现中，涉及到的一些Java计算环境的底层技术；尽管对应用开发人员来说，可能不会直接去涉及这些JVM虚拟机底层实现的工作，但是了解这些背景知识，或多或少，对我们了解整个Spring平台的应用背景有很大的帮助；打个比方来说，就像我们在大学中，学习的那些关于计算机组织和系统方面的基本知识，比如像数字电路，计算机组成原理，汇编语言，操作系统等等这些基本课程的学习。虽然，坦率的来说，对我们这些大多数课程的学习者，在以后的工作中，可能并没有太多的机会，直接从事这么如此底层的技术开发工作；但具备这些知识背景，为我们深入理解基于这些基础技术构架起来的应用系统，毫无疑问，是不可缺少的。随着JVM虚拟机技术的发展，可以设想到的是，更多虚拟机级别的基本特性，将会持续的被应用平台开发者所关注和采用，这也是我们在学习平台实现的过程中，非常值得注意的一点，因为这些底层技术实现，毫无疑问，会对Spring应用平台的开发路线，产品策略产生重大的影响。同时，在使用Spring作为应用平台的时候，如果需要更深层次的开发和性能调优，这些底层的知识，也是我们知识库中不可缺少的部分。有了这些底层知识，理解整个系统，想来就应该障碍不大了。

IOC的一点认识

对Spring IOC的理解离不开对依赖反转模式的理解，我们知道，关于如何反转对依赖的控制，把控制权从具体业务对象手中转交到平台或者框架中，是解决面向对象系统设计复杂性和提高面向对象系统可测试性的一个有效的解决方案。这个问题触发了IoC设计模式的发展，是IoC容器要解决的核心问题。同时，也是产品化的IoC容器出现的推动力。而我觉得Spring的IoC容器，就是一个开源的实现依赖反转模式的产品。

那具体什么是IoC容器呢？它在Spring框架中到底长什么样？说了这么多，其实对IoC容器的使用者来说，我们常常接触到的BeanFactory和ApplicationContext都可以看成是容器的具体表现形式。这些就是IoC容器，或者说在Spring中提IoC容器，从实现来说，指的是一个容器系列。这也就是说，我们通常所说的IoC容器，如果深入到Spring的实现去看，会发现IoC容器实际上代表着一系列功能各异的容器产品。只是容器的功能有大有小，有各自的特点。打个比方来说，就像是百货商店里出售的商品，我们举水桶为例子，在商店中出售的水桶有大有小；制作材料也各不相同，有金属的，有塑料的等等，总之是各式各样，但只要能装水，具备水桶的基本特性，那就可以作为水桶来出售来让用户使用。这在Spring中也是一样，它有各式各样的IoC容器的实现供用户选择和使用；使用什么样的容器完全取决于用户的需要，但在使用之前如果能够了解容器的基本情况，那会对容器的使用是非常有帮助的；就像我们在购买商品时进行的对商品的考察和挑选那样。

我们从最基本的==XmlBeanFactory==看起，==它是容器系列的最底层实现==，这个容器的实现与我们在Spring应用中用到的那些上下文相比，有一个非常明显的特点，它只提供了最基本的IoC容器的功能。从它的名字中可以看出，这个IoC容器可以读取以XML形式定义的BeanDefinition。理解这一点有助于我们理解ApplicationContext与基本的BeanFactory之间的区别和联系。我们可以认为直接的BeanFactory实现是IoC容器的基本形式，而各种ApplicationContext的实现是IoC容器的高级表现形式。

仔细阅读XmlBeanFactory的源码，在一开始的注释里面已经对 XmlBeanFactory的功能做了简要的说明，从代码的注释还可以看到，这是Rod Johnson在2001年就写下的代码，可见这个类应该是Spring的元老类了。它是继承DefaultListableBeanFactory这个类的，这个DefaultListableBeanFactory就是一个很值得注意的容器！

public class XmlBeanFactory extends DefaultListableBeanFactory {
    private final XmlBeanDefinitionReader reader = new XmlBeanDefinitionReader(this);
    public XmlBeanFactory(Resource resource) throws BeansException {
        this(resource, null);
    }
    public XmlBeanFactory(Resource resource, BeanFactory parentBeanFactory) throws BeansException {
        super(parentBeanFactory);
        this.reader.loadBeanDefinitions(resource);
    }
}

==XmlBeanFactory的功能是建立在DefaultListableBeanFactory这个基本容器的基础上的，在这个基本容器的基础上实现了其他诸如XML读取的附加功能==。对于这些功能的实现原理，看一看XmlBeanFactory的代码实现就能很容易地理解。在如下的代码中可以看到，在XmlBeanFactory构造方法中需要得到Resource对象。对XmlBeanDefinitionReader对象的初始化，以及使用这个这个对象来完成loadBeanDefinitions的调用，就是这个调用启动了从Resource中载入BeanDefinitions的过程，这个loadBeanDefinitions同时也是IoC容器初始化的重要组成部分。

简单来说，==IoC容器的初始化包括BeanDefinition的Resouce定位、载入和注册这三个基本的过程==。我觉得重点是在载入和对BeanDefinition做解析的这个过程。==可以从DefaultListableBeanFactory来入手看看IoC容器是怎样完成BeanDefinition载入的==。在refresh调用完成以后，可以看到loadDefinition的调用：

public abstract class AbstractXmlApplicationContext extends AbstractRefreshableConfigApplicationContext {
    public AbstractXmlApplicationContext() {
    }
    public AbstractXmlApplicationContext(ApplicationContext parent) {
        super(parent);
    }
    //这里是实现loadBeanDefinitions的地方
    protected void loadBeanDefinitions(DefaultListableBeanFactory beanFactory) throws IOException {
        // Create a new XmlBeanDefinitionReader for the given BeanFactory.
        // 创建 XmlBeanDefinitionReader，并通过回调设置到 BeanFactory中去，创建BeanFactory的使用的也是 DefaultListableBeanFactory。
        XmlBeanDefinitionReader beanDefinitionReader = new XmlBeanDefinitionReader(beanFactory);

        // Configure the bean definition reader with this context's
        // resource loading environment.
        // 这里设置 XmlBeanDefinitionReader， 为XmlBeanDefinitionReader 配置ResourceLoader，因为DefaultResourceLoader是父类，所以this可以直接被使用
        beanDefinitionReader.setResourceLoader(this);
        beanDefinitionReader.setEntityResolver(new ResourceEntityResolver(this));

        // Allow a subclass to provide custom initialization of the reader,
        // then proceed with actually loading the bean definitions.
    // 这是启动Bean定义信息载入的过程
        initBeanDefinitionReader(beanDefinitionReader);
        loadBeanDefinitions(beanDefinitionReader);
    }

    protected void initBeanDefinitionReader(XmlBeanDefinitionReader beanDefinitionReader) {
    }

这里==使用 XmlBeanDefinitionReader来载入BeanDefinition到容中==，如以下代码清单所示：

    //这里是调用的入口。
    public int loadBeanDefinitions(Resource resource) throws BeanDefinitionStoreException {
        return loadBeanDefinitions(new EncodedResource(resource));
    }
    //这里是载入XML形式的BeanDefinition的地方。
    public int loadBeanDefinitions(EncodedResource encodedResource) throws BeanDefinitionStoreException {
        Assert.notNull(encodedResource, "EncodedResource must not be null");
        if (logger.isInfoEnabled()) {
            logger.info("Loading XML bean definitions from " + encodedResource.getResource());
        }

        Set<EncodedResource> currentResources = this.resourcesCurrentlyBeingLoaded.get();
        if (currentResources == null) {
            currentResources = new HashSet<EncodedResource>(4);
            this.resourcesCurrentlyBeingLoaded.set(currentResources);
        }
        if (!currentResources.add(encodedResource)) {
            throw new BeanDefinitionStoreException(
                    "Detected recursive loading of " + encodedResource + " - check your import definitions!");
        }
        //这里得到XML文件，并得到IO的InputSource准备进行读取。
        try {
            InputStream inputStream = encodedResource.getResource().getInputStream();
            try {
                InputSource inputSource = new InputSource(inputStream);
                if (encodedResource.getEncoding() != null) {
                    inputSource.setEncoding(encodedResource.getEncoding());
                }
                return doLoadBeanDefinitions(inputSource, encodedResource.getResource());
            }
            finally {
                inputStream.close();
            }
        }
        catch (IOException ex) {
            throw new BeanDefinitionStoreException(
                    "IOException parsing XML document from " + encodedResource.getResource(), ex);
        }
        finally {
            currentResources.remove(encodedResource);
            if (currentResources.isEmpty()) {
                this.resourcesCurrentlyBeingLoaded.set(null);
            }
        }
    }
//具体的读取过程可以在doLoadBeanDefinitions方法中找到：
    //这是从特定的XML文件中实际载入BeanDefinition的地方
    protected int doLoadBeanDefinitions(InputSource inputSource, Resource resource)
            throws BeanDefinitionStoreException {
        try {
            int validationMode = getValidationModeForResource(resource);
            //这里取得XML文件的Document对象，这个解析过程是由 documentLoader完成的，这个documentLoader是DefaultDocumentLoader,在定义documentLoader的地方创建
            Document doc = this.documentLoader.loadDocument(
                    inputSource, getEntityResolver(), this.errorHandler, validationMode, isNamespaceAware());
            //这里启动的是对BeanDefinition解析的详细过程，这个解析会使用到Spring的Bean配置规则，是我们下面需要详细关注的地方。
            return registerBeanDefinitions(doc, resource);
        }
        catch (BeanDefinitionStoreException ex) {
            throw ex;
        }
        catch (SAXParseException ex) {
            throw new XmlBeanDefinitionStoreException(resource.getDescription(),
                    "Line " + ex.getLineNumber() + " in XML document from " + resource + " is invalid", ex);
        }
        catch (SAXException ex) {
            throw new XmlBeanDefinitionStoreException(resource.getDescription(),
                    "XML document from " + resource + " is invalid", ex);
        }
        catch (ParserConfigurationException ex) {
            throw new BeanDefinitionStoreException(resource.getDescription(),
                    "Parser configuration exception parsing XML from " + resource, ex);
        }
        catch (IOException ex) {
            throw new BeanDefinitionStoreException(resource.getDescription(),
                    "IOException parsing XML document from " + resource, ex);
        }
        catch (Throwable ex) {
            throw new BeanDefinitionStoreException(resource.getDescription(),
                    "Unexpected exception parsing XML document from " + resource, ex);
        }
    }

关于具体的Spring BeanDefinition的解析，是在BeanDefinitionParserDelegate中完成的。这个类里包含了各种Spring Bean定义规则的处理，感兴趣的同学可以仔细研究。我们举一个例子来分析这个处理过程，比如我们最熟悉的对Bean元素的处理是怎样完成的，也就是我们在XML定义文件中出现的<bean></bean>这个最常见的元素信息是怎样被处理的。在这里，我们会看到那些熟悉的BeanDefinition定义的处理，比如id、name、aliase等属性元素。把这些元素的值从XML文件相应的元素的属性中读取出来以后，会被设置到生成的BeanDefinitionHolder中去。这些属性的解析还是比较简单的。对于其他元素配置的解析，比如各种Bean的属性配置，通过一个较为复杂的解析过程，这个过程是由parseBeanDefinitionElement来完成的。解析完成以后，会把解析结果放到BeanDefinition对象中并设置到BeanDefinitionHolder中去，如以下清单所示：

public BeanDefinitionHolder parseBeanDefinitionElement(Element ele, BeanDefinition containingBean) {
        //这里取得在<bean>元素中定义的id、name和aliase属性的值
        String id = ele.getAttribute(ID_ATTRIBUTE);
        String nameAttr = ele.getAttribute(NAME_ATTRIBUTE);

        List<String> aliases = new ArrayList<String>();
        if (StringUtils.hasLength(nameAttr)) {
            String[] nameArr = StringUtils.tokenizeToStringArray(nameAttr, BEAN_NAME_DELIMITERS);
            aliases.addAll(Arrays.asList(nameArr));
        }

        String beanName = id;
        if (!StringUtils.hasText(beanName) && !aliases.isEmpty()) {
            beanName = aliases.remove(0);
            if (logger.isDebugEnabled()) {
                logger.debug("No XML 'id' specified - using '" + beanName +
                        "' as bean name and " + aliases + " as aliases");
            }
        }

        if (containingBean == null) {
            checkNameUniqueness(beanName, aliases, ele);
        }

        //这个方法会引发对bean元素的详细解析
AbstractBeanDefinition beanDefinition = parseBeanDefinitionElement(ele, beanName, containingBean);
        if (beanDefinition != null) {
            if (!StringUtils.hasText(beanName)) {
                try {
                    if (containingBean != null) {
                        beanName = BeanDefinitionReaderUtils.generateBeanName(
                                beanDefinition, this.readerContext.getRegistry(), true);
                    }
                    else {
                        beanName = this.readerContext.generateBeanName(beanDefinition);
                        // Register an alias for the plain bean class name, if still possible,
                        // if the generator returned the class name plus a suffix.
                        // This is expected for Spring 1.2/2.0 backwards compatibility.
                        String beanClassName = beanDefinition.getBeanClassName();
                        if (beanClassName != null &&
                                beanName.startsWith(beanClassName) && beanName.length() > beanClassName.length() &&
                                !this.readerContext.getRegistry().isBeanNameInUse(beanClassName)) {
                            aliases.add(beanClassName);
                        }
                    }
                    if (logger.isDebugEnabled()) {
                        logger.debug("Neither XML 'id' nor 'name' specified - " +
                                "using generated bean name [" + beanName + "]");
                    }
                }
                catch (Exception ex) {
                    error(ex.getMessage(), ele);
                    return null;
                }
            }
            String[] aliasesArray = StringUtils.toStringArray(aliases);
            return new BeanDefinitionHolder(beanDefinition, beanName, aliasesArray);
        }

        return null;
    }

在具体生成BeanDefinition以后。我们举一个对property进行解析的例子来完成对整个BeanDefinition载入过程的分析，还是在类BeanDefinitionParserDelegate的代码中，它对BeanDefinition中的定义一层一层地进行解析，比如从属性元素集合到具体的每一个属性元素，然后才是对具体的属性值的处理。根据解析结果，对这些属性值的处理会封装成PropertyValue对象并设置到BeanDefinition对象中去，如以下代码清单所示。

    /**
     * 这里对指定bean元素的property子元素集合进行解析。
     */
    public void parsePropertyElements(Element beanEle, BeanDefinition bd) {
        //遍历所有bean元素下定义的property元素
        NodeList nl = beanEle.getChildNodes();
        for (int i = 0; i < nl.getLength(); i++) {
            Node node = nl.item(i);
            if (node instanceof Element && DomUtils.nodeNameEquals(node, PROPERTY_ELEMENT)) {
                //在判断是property元素后对该property元素进行解析的过程
                parsePropertyElement((Element) node, bd);
            }
        }
    }
    public void parsePropertyElement(Element ele, BeanDefinition bd) {
        //这里取得property的名字
        String propertyName = ele.getAttribute(NAME_ATTRIBUTE);
        if (!StringUtils.hasLength(propertyName)) {
            error("Tag 'property' must have a 'name' attribute", ele);
            return;
        }
        this.parseState.push(new PropertyEntry(propertyName));
        try {
            //如果同一个bean中已经有同名的存在，则不进行解析，直接返回。也就是说，如果在同一个bean中有同名的property设置，那么起作用的只是第一个。
            if (bd.getPropertyValues().contains(propertyName)) {
                error("Multiple 'property' definitions for property '" + propertyName + "'", ele);
                return;
            }
            //这里是解析property值的地方，返回的对象对应对Bean定义的property属性设置的解析结果，这个解析结果会封装到PropertyValue对象中，然后设置到BeanDefinitionHolder中去。
            Object val = parsePropertyValue(ele, bd, propertyName);
            PropertyValue pv = new PropertyValue(propertyName, val);
            parseMetaElements(ele, pv);
            pv.setSource(extractSource(ele));
            bd.getPropertyValues().addPropertyValue(pv);
        }
        finally {
            this.parseState.pop();
        }
    }
    /**
     * 这里取得property元素的值，也许是一个list或其他。
     */
    public Object parsePropertyValue(Element ele, BeanDefinition bd, String propertyName) {
        String elementName = (propertyName != null) ?
                        "<property> element for property '" + propertyName + "'" :
                        "<constructor-arg> element";

        // Should only have one child element: ref, value, list, etc.
        NodeList nl = ele.getChildNodes();
        Element subElement = null;
        for (int i = 0; i < nl.getLength(); i++) {
            Node node = nl.item(i);
            if (node instanceof Element && !DomUtils.nodeNameEquals(node, DESCRIPTION_ELEMENT) &&
                    !DomUtils.nodeNameEquals(node, META_ELEMENT)) {
                // Child element is what we're looking for.
                if (subElement != null) {
                    error(elementName + " must not contain more than one sub-element", ele);
                }
                else {
                    subElement = (Element) node;
                }
            }
        }
        //这里判断property的属性，是ref还是value,不允许同时是ref和value。
        boolean hasRefAttribute = ele.hasAttribute(REF_ATTRIBUTE);
        boolean hasValueAttribute = ele.hasAttribute(VALUE_ATTRIBUTE);
        if ((hasRefAttribute && hasValueAttribute) ||
                ((hasRefAttribute || hasValueAttribute) && subElement != null)) {
            error(elementName +
                    " is only allowed to contain either 'ref' attribute OR 'value' attribute OR sub-element", ele);
        }
        //如果是ref，创建一个ref的数据对象RuntimeBeanReference,这个对象封装了ref的信息。
        if (hasRefAttribute) {
            String refName = ele.getAttribute(REF_ATTRIBUTE);
            if (!StringUtils.hasText(refName)) {
                error(elementName + " contains empty 'ref' attribute", ele);
            }
            RuntimeBeanReference ref = new RuntimeBeanReference(refName);
            ref.setSource(extractSource(ele));
            return ref;
        } //如果是value，创建一个value的数据对象TypedStringValue ,这个对象封装了value的信息。
        else if (hasValueAttribute) {
            TypedStringValue valueHolder = new TypedStringValue(ele.getAttribute(VALUE_ATTRIBUTE));
            valueHolder.setSource(extractSource(ele));
            return valueHolder;
        } //如果还有子元素，触发对子元素的解析
        else if (subElement != null) {
            return parsePropertySubElement(subElement, bd);
        }
        else {
            // Neither child element nor "ref" or "value" attribute found.
            error(elementName + " must specify a ref or value", ele);
            return null;
        }
    }

比如，再往下看，我们看到像List这样的属性配置是怎样被解析的，依然在BeanDefinitionParserDelegate中：返回的是一个List对象，这个List是Spring定义的ManagedList，作为封装List这类配置定义的数据封装，如以下代码清单所示。

    public List parseListElement(Element collectionEle, BeanDefinition bd) {
        String defaultElementType = collectionEle.getAttribute(VALUE_TYPE_ATTRIBUTE);
        NodeList nl = collectionEle.getChildNodes();
        ManagedList<Object> target = new ManagedList<Object>(nl.getLength());
        target.setSource(extractSource(collectionEle));
        target.setElementTypeName(defaultElementType);
        target.setMergeEnabled(parseMergeAttribute(collectionEle));
        //具体的List元素的解析过程。
        parseCollectionElements(nl, target, bd, defaultElementType);
        return target;
    }
    protected void parseCollectionElements(
            NodeList elementNodes, Collection<Object> target, BeanDefinition bd, String defaultElementType) {
        //遍历所有的元素节点，并判断其类型是否为Element。
        for (int i = 0; i < elementNodes.getLength(); i++) {
            Node node = elementNodes.item(i);
            if (node instanceof Element && !DomUtils.nodeNameEquals(node, DESCRIPTION_ELEMENT)) {
        //加入到target中去，target是一个ManagedList，同时触发对下一层子元素的解析过程，这是一个递归的调用。
                target.add(parsePropertySubElement((Element) node, bd, defaultElementType));
            }
        }
    }

经过这样一层一层的解析，我们在XML文件中定义的BeanDefinition就被整个给载入到了IoC容器中，并在容器中建立了数据映射。在IoC容器中建立了对应的数据结构，或者说可以看成是POJO对象在IoC容器中的映像，这些数据结构可以以AbstractBeanDefinition为入口，让IoC容器执行索引、查询和操作。

在我的感觉中，对核心数据结构的定义和处理应该可以看成是一个软件的核心部分了。所以，这里的BeanDefinition的载入可以说是IoC容器的核心，如果说IoC容器是Spring的核心，那么这些BeanDefinition就是Spring的核心的核心了！

clipboard.png

AOP理解（Aspect Oriented Programming）面向切面编程

转自：http://jiwenke.iteye.com/blog/494620

AOP粗解

AOP联盟定义的AOP体系结构把与AOP相关的概念大致分为了由高到低、从使用到实现的三个层次。关于这个体系结构，个人的理解是这样的，==从上往下，最高层是语言和开发环境==，在这个环境中可以看到几个重要的概念：==base可以视为待增强对象，或者说目标对象==；==aspect指切面==，通常包含对于base的增强应用；==configuration可以看成是一种编织或者说配置==，通过在AOP体系中提供这个configuration配置环境，可以把base和aspect结合起来，从而完成切面对目标对象的编织实现。

对Spring平台或者说生态系统来说，AOP是Spring框架的核心功能模块之一。AOP与IOC容器的结合使用, 为应用开发或者Spring==自身功能的扩展==都提供了许多便利。Spring AOP的实现和其他特性的实现一样，非常丰富，除了可以使用Spring本身提供的AOP实现之外，还封装了业界优秀的AOP解决方案AspectJ来让应用使用。在这里，主要对Spring自身的AOP实现原理做一些解析；在这个AOP实现中，==Spring充分利用了IOC容器Proxy代理对象以及AOP拦截器的功能特性，通过这些对AOP基本功能的封装机制，为用户提供了AOP的实现框架==。所以，要了解这些AOP的基本实现，需要我们对Java 的Proxy机制有一些基本了解。

AOP实现的基本线索

AOP实现中，可以看到三个主要的步骤，一个是==代理对象的生成==，然后是==拦截器的作用==，然后是==Aspect编织的实现==。AOP框架的丰富，很大程度体现在这三个具体实现中，所具有的丰富的技术选择，以及如何==实现与IOC容器的无缝结合==。毕竟这也是一个非常核心的模块，需要满足不同的应用需求带来的解决方案需求。
在Spring AOP的实现原理中，我们主要举ProxyFactoryBean的实现作为例子和实现的基本线索进行分析；很大一个原因，是因为ProxyFactoryBean是在Spring IoC环境中，创建AOP应用的最底层方法，从中，可以看到一条实现AOP的基本线索。在ProxyFactoryBean中，它的AOP实现需要依赖JDK或者CGLIB提供的Proxy特性。从FactoryBean中获取对象，是从getObject()方法作为入口完成的。然后为proxy代理对象配置advisor链，这个配置是在initializeAdvisorChain方法中完成的；然后就为生成AOP代理对象做好了准备，生成代理对象如下所示：

    private synchronized Object getSingletonInstance() {
        if (this.singletonInstance == null) {
            this.targetSource = freshTargetSource();
            if (this.autodetectInterfaces && getProxiedInterfaces().length == 0 && !isProxyTargetClass()) {
                // Rely on AOP infrastructure to tell us what interfaces to proxy.
                Class targetClass = getTargetClass();
                if (targetClass == null) {
                    throw new FactoryBeanNotInitializedException("Cannot determine target class for proxy");
                }
     // 这里设置代理对象的接口     setInterfaces(ClassUtils.getAllInterfacesForClass(targetClass, this.proxyClassLoader));
            }
            // Initialize the shared singleton instance.
            super.setFrozen(this.freezeProxy);
            // 注意这里的方法会使用ProxyFactory来生成我们需要的Proxy
            this.singletonInstance = getProxy(createAopProxy());
        }
        return this.singletonInstance;
    }
    //使用createAopProxy返回的AopProxy来得到代理对象
    protected Object getProxy(AopProxy aopProxy) {
        return aopProxy.getProxy(this.proxyClassLoader);
    }

上面我们看到了在Spring中通过ProxyFactoryBean实现AOP功能的第一步，得到AopProxy代理对象的基本过程，下面我们看看AopProxy代理对象的拦截机制是怎样发挥作用，是怎样实现AOP功能的。我们知道，对代理对象的生成，有CGLIB和JDK两种生成方式，在CGLIB中，对拦截器设计是通过在Cglib2AopProxy的AopProxy代理对象生成的时候，在回调DynamicAdvisedInterceptor对象中实现的，这个回调的实现在intercept方法中完成。对于AOP是怎样完成对目标对象的增强的，这些实现是封装在AOP拦截器链中，由一个个具体的拦截器来完成的。具体拦截器的运行是在以下的代码实现中完成的，这些调用在ReflectiveMethodInvocation中。

    public Object proceed() throws Throwable {
        //  We start with an index of -1 and increment early.
        //如果拦截器链中的拦截器迭代调用完毕，这里开始调用target的函数，这个函数是通过反射机制完成的,具体实现在：AopUtils.invokeJoinpointUsingReflection方法里面。
        if (this.currentInterceptorIndex == this.interceptorsAndDynamicMethodMatchers.size() - 1) {
            return invokeJoinpoint();
        }
        //这里沿着定义好的 interceptorOrInterceptionAdvice链进行处理。
        Object interceptorOrInterceptionAdvice =
            this.interceptorsAndDynamicMethodMatchers.get(++this.currentInterceptorIndex);
        if (interceptorOrInterceptionAdvice instanceof InterceptorAndDynamicMethodMatcher) {
            // Evaluate dynamic method matcher here: static part will already have
            // been evaluated and found to match.
            //这里对拦截器进行动态匹配的的判断，还记得我们前面分析的pointcut吗？这里是触发进行匹配的地方，如果和定义的pointcut匹配，那么这个advice将会得到执行。
            InterceptorAndDynamicMethodMatcher dm =
                (InterceptorAndDynamicMethodMatcher) interceptorOrInterceptionAdvice;
            if (dm.methodMatcher.matches(this.method, this.targetClass, this.arguments)) {
                return dm.interceptor.invoke(this);
            }
            else {
                // Dynamic matching failed.
                // Skip this interceptor and invoke the next in the chain.
                // //如果不匹配，那么这个proceed会被递归调用，直到所有的拦截器都被运行过为止。
                return proceed();
            }
        }
        else {
            // It's an interceptor, so we just invoke it: The pointcut will have
            // been evaluated statically before this object was constructed.
            //如果是一个interceptor，直接调用这个interceptor对应的方法
            return((MethodInterceptor) interceptorOrInterceptionAdvice).invoke(this);
        }
    }

在调用拦截器的时候，我们接下去就可以看到对advice的通知的调用。而经过一系列的注册，适配的过程以后，拦截器在拦截的时候，会调用到预置好的一个通知适配器，设置通知拦截器，这是一系列Spring设计好为通知服务的类的一个，是==最终完成通知拦截和实现的地方==，非常的关键。比如，对MethodBeforeAdviceInterceptor的实现是这样的：

public class MethodBeforeAdviceInterceptor implements MethodInterceptor, Serializable {

    private MethodBeforeAdvice advice;


    /**
     * Create a new MethodBeforeAdviceInterceptor for the given advice.
     * @param advice the MethodBeforeAdvice to wrap
     */
    public MethodBeforeAdviceInterceptor(MethodBeforeAdvice advice) {
        Assert.notNull(advice, "Advice must not be null");
        this.advice = advice;
    }
    //这个invoke方法是拦截器的回调方法，会在代理对象的方法被调用的时候触发回调。
    public Object invoke(MethodInvocation mi) throws Throwable {
        this.advice.before(mi.getMethod(), mi.getArguments(), mi.getThis() );
        return mi.proceed();
    }
}

在代码中，可以看到，就是这里，会调用advice的before方法！这样就成功的完成了before通知的编织！

因为Spring AOP本身并不打算成为一个一统天下的AOP框架，秉持Spring的一贯设计理念，设想中的Spring设计目标应该是，致力于AOP框架与IOC容器的紧密集成，通过集成AOP技术为JavaEE应用开发中遇到的普遍问题提供解决方案，从而为AOP用户使用AOP技术提供最大的便利，从这个角度上为Java EE的应用开发人员服务。在没有使用第三方AOP解决方案的时候，Spring通过虚拟机的Proxy特性和CGLIB实现了AOP的基本功能，我想，如果有了Spring AOP实现原理的知识背景，再加上我们对源代码实现的认真解读，可以为我们了解其他AOP框架与IOC容器的集成原理，也打下了很好的基础，并真正了解一个AOP框架是在怎样实现的。

数据库的操作实现

关于Spring JDBC

还是从Spring JDBC说起吧，虽然现在应用很多都是直接使用Hibernate或者其他的ORM工具。但JDBC毕竟还是很基本的，其中的JdbcTemplate就是我们经常使用的，比如JDBCTemplate的execute方法，就是一个基本的方法，在这个方法的实现中，可以看到对数据库操作的基本过程。

    //execute方法执行的是输入的sql语句
    public void execute(final String sql) throws DataAccessException {
        if (logger.isDebugEnabled()) {
            logger.debug("Executing SQL statement [" + sql + "]");
        }
        class ExecuteStatementCallback implements StatementCallback<Object>, SqlProvider {
            public Object doInStatement(Statement stmt) throws SQLException {
                stmt.execute(sql);
                return null;
            }
            public String getSql() {
                return sql;
            }
        }
        execute(new ExecuteStatementCallback());
    }
    //这是使用java.sql.Statement处理静态SQL语句的方法
    public <T> T execute(StatementCallback<T> action) throws DataAccessException {
        Assert.notNull(action, "Callback object must not be null");
        //这里取得数据库的Connection，这个数据库的Connection已经在Spring的事务管理之下
        Connection con = DataSourceUtils.getConnection(getDataSource());
        Statement stmt = null;
        try {
            Connection conToUse = con;
            if (this.nativeJdbcExtractor != null &&
                    this.nativeJdbcExtractor.isNativeConnectionNecessaryForNativeStatements()) {
                conToUse = this.nativeJdbcExtractor.getNativeConnection(con);
            }
            //创建Statement
            stmt = conToUse.createStatement();
            applyStatementSettings(stmt);
            Statement stmtToUse = stmt;
            if (this.nativeJdbcExtractor != null) {
                stmtToUse = this.nativeJdbcExtractor.getNativeStatement(stmt);
            }
            //这里调用回调函数
            T result = action.doInStatement(stmtToUse);
            handleWarnings(stmt);
            return result;
        }
        catch (SQLException ex) {
            // Release Connection early, to avoid potential connection pool deadlock
            // in the case when the exception translator hasn't been initialized yet.
            //如果捕捉到数据库异常，把数据库Connection释放，同时抛出一个经过Spring转换过的Spring数据库异常
            //Spring做了一项有意义的工作，就是把这些数据库异常统一到自己的异常体系里了
            JdbcUtils.closeStatement(stmt);
            stmt = null;
            DataSourceUtils.releaseConnection(con, getDataSource());
            con = null;
            throw getExceptionTranslator().translate("StatementCallback", getSql(action), ex);
        }
        finally {
            JdbcUtils.closeStatement(stmt);
            //释放数据库connection
            DataSourceUtils.releaseConnection(con, getDataSource());
        }
    }

在使用数据库的时候，有一个很重要的地方就是对数据库连接的管理，在这里，是由DataSourceUtils来完成的。Spring通过这个辅助类来对数据的Connection进行管理。比如通过它来完成打开和关闭Connection等操作。DataSourceUtils对这些数据库Connection管理的实现, 如以下代码所示。

    //这是取得数据库连接的调用，实现是通过调用doGetConnection完成的，这里执行了异常的转换操作
    public static Connection getConnection(DataSource dataSource) throws CannotGetJdbcConnectionException {
        try {
            return doGetConnection(dataSource);
        }
        catch (SQLException ex) {
            throw new CannotGetJdbcConnectionException("Could not get JDBC Connection", ex);
        }
    }
    public static Connection doGetConnection(DataSource dataSource) throws SQLException {
        Assert.notNull(dataSource, "No DataSource specified");
        //把对数据库的Connection放到事务管理中进行管理，这里使用TransactionSynchronizationManager中定义的ThreadLocal变量来和线程绑定数据库连接
        //如果在TransactionSynchronizationManager中已经有与当前线程绑定数据库连接，那就直接取出来使用
        ConnectionHolder conHolder = (ConnectionHolder) TransactionSynchronizationManager.getResource(dataSource);
        if (conHolder != null && (conHolder.hasConnection() || conHolder.isSynchronizedWithTransaction())) {
            conHolder.requested();
            if (!conHolder.hasConnection()) {
                logger.debug("Fetching resumed JDBC Connection from DataSource");
                conHolder.setConnection(dataSource.getConnection());
            }
            return conHolder.getConnection();
        }
        // Else we either got no holder or an empty thread-bound holder here.
        // 这里得到需要的数据库Connection，在Bean配置文件中定义好的，
        // 同时最后把新打开的数据库Connection通过TransactionSynchronizationManager和当前线程绑定起来。
        logger.debug("Fetching JDBC Connection from DataSource");
        Connection con = dataSource.getConnection();

        if (TransactionSynchronizationManager.isSynchronizationActive()) {
            logger.debug("Registering transaction synchronization for JDBC Connection");
            // Use same Connection for further JDBC actions within the transaction.
            // Thread-bound object will get removed by synchronization at transaction completion.
            ConnectionHolder holderToUse = conHolder;
            if (holderToUse == null) {
                holderToUse = new ConnectionHolder(con);
            }
            else {
                holderToUse.setConnection(con);
            }
            holderToUse.requested();
            TransactionSynchronizationManager.registerSynchronization(
                    new ConnectionSynchronization(holderToUse, dataSource));
            holderToUse.setSynchronizedWithTransaction(true);
            if (holderToUse != conHolder) {
                TransactionSynchronizationManager.bindResource(dataSource, holderToUse);
            }
        }
        return con;
    }

关于数据库操作类RDBMS

从JdbcTemplate中，我们看到，他提供了许多简单查询和更新的功能。但是，如果需要更高层次的抽象，以及更面向对象的方法来访问数据库，Spring为我们提供了org.springframework.jdbc.object包，里面包含了SqlQuery、SqlMappingQuery、SqlUpdate和StoredProcedure等类，这些类都是Spring JDBC应用程序可以使用的。但要注意，在使用这些类时需要为它们配置好JdbcTemplate作为其基本的操作实现，因为在它们的功能实现中，对数据库操作的那部分实现基本上还是依赖于JdbcTemplate来完成的。

比如，对MappingSqlQuery使用的过程，是非常简洁的；在设计好数据的映射代码之后，查询得到的记录已经按照前面的设计转换为对象List了，一条查询记录对应于一个数据对象，可以把数据库的数据记录直接映射成Java对象在程序中使用，同时又可避免使用第三方ORM工具的配置，对于简单的数据映射场合是非常方便的；在mapRow方法的实现中提供的数据转换规则，和我们使用Hibernate时，Hibernate的hbm文件起到的作用是非常类似的。这个MappingSqlQuery需要的对设置进行compile，这些compile是这样完成的，如以下代码所示：

    protected final void compileInternal() {
        //这里是对参数的compile过程，所有的参数都在getDeclaredParameters里面，生成了一个PreparedStatementCreatorFactory
        this.preparedStatementFactory = new PreparedStatementCreatorFactory(getSql(), getDeclaredParameters());
        this.preparedStatementFactory.setResultSetType(getResultSetType());
        this.preparedStatementFactory.setUpdatableResults(isUpdatableResults());
        this.preparedStatementFactory.setReturnGeneratedKeys(isReturnGeneratedKeys());
        if (getGeneratedKeysColumnNames() != null) {
            this.preparedStatementFactory.setGeneratedKeysColumnNames(getGeneratedKeysColumnNames());
        }
this.preparedStatementFactory.setNativeJdbcExtractor(getJdbcTemplate().getNativeJdbcExtractor());
        onCompileInternal();
    }

在执行查询时，执行的实际上是SqlQuery的executeByNamedParam方法，这个方法需要完成的工作包括配置SQL语句，配置数据记录到数据对象的转换的RowMapper，然后使用JdbcTemplate来完成数据的查询，并启动数据记录到Java数据对象的转换，如以下代码所示：

    public List<T> executeByNamedParam(Map<String, ?> paramMap, Map context) throws DataAccessException {
        validateNamedParameters(paramMap);
        //得到需要执行的SQL语句
        ParsedSql parsedSql = getParsedSql();
        MapSqlParameterSource paramSource = new MapSqlParameterSource(paramMap);
        String sqlToUse = NamedParameterUtils.substituteNamedParameters(parsedSql, paramSource);
        //配置好SQL语句需要的Parameters及rowMapper，这个rowMapper完成数据记录到对象的转换
        Object[] params = NamedParameterUtils.buildValueArray(parsedSql, paramSource, getDeclaredParameters());
        RowMapper<T> rowMapper = newRowMapper(params, context);
        //我们又看到了JdbcTemplate,这里使用JdbcTemplate来完成对数据库的查询操作，所以我们说JdbcTemplate是非常基本的操作类
        return getJdbcTemplate().query(newPreparedStatementCreator(sqlToUse, params), rowMapper);
    }

在Spring对JDBC的操作中，基本上是对JDBC/Hibernate基础上API的封装。这些封装可以直接使用，也可以在IoC容器中配置好了再使用，当结合IoC容器的基础上进行使用的时候，可以看到许多和事务管理相关的处理部分，都是非常值得学习的，在那里，可以看到对数据源的管理 - Hibernate中session的管理，与线程的结合等等。

Web MVC的实现

spring web mvc的实现

关于MVC，这是和WEB开发相关的部分，显然大家都是很熟悉了。从最初的JSP到struts，再到像wicket等等，真是百花齐放，百家争鸣.在WEB UI上，这部分是做web应用架构选择不可缺少的一部分。而作为MVC框架，也许SPRING MVC不能算得上是表现力最出色的UI框架，但无疑，它的实现也是非常的优秀，同时，我们可以从它的实现上，看到一个非常清晰的MVC实现的过程，从这点上看，真是非常的过瘾啊！

在了解IOC容器的基本实现的基础上，下面我们来看看，在典型的Web环境中，Spring IOC容器是如何在Web环境中被载入并起作用的。我们可以看到，对于MVC这部分，主要建立在IOC的基础上，AOP的特性应用得并不多。Spring并不是天生就能在Web容器中起作用的，同样也需要一个启动过程，把自己的IOC容器导入，并在Web容器中建立起来。

与对IoC容器的初始化的分析一样，我们同样看到了loadBeanDefinition对BeanDefinition的载入。在Web环境中，对定位BeanDefinition的Resource有特别的要求，对这个要求的处理体现在getDefaultConfigLocations方法的处理中。可以看到，在这里，使用了默认的BeanDefinition的配置路径，这个路径在XmlWebApplicationContext中，已经作为一个常量定义好了，这个常量就是/WEB-INF/applicationContext.xml。这里的loadBeanDefinition实现如下所示：

public class XmlWebApplicationContext extends AbstractRefreshableWebApplicationContext {

    /** Default config location for the root context */
    //这里是设置缺省BeanDefinition的地方，在/WEB-INF/applicationContext.xml文件里，如果不特殊指定其他文件，IoC容器会从这里读取BeanDefinition来初始化IoC容器
    public static final String DEFAULT_CONFIG_LOCATION = "/WEB-INF/applicationContext.xml";

    /** Default prefix for building a config location for a namespace */
    public static final String DEFAULT_CONFIG_LOCATION_PREFIX = "/WEB-INF/";

    /** Default suffix for building a config location for a namespace */
    public static final String DEFAULT_CONFIG_LOCATION_SUFFIX = ".xml";
    //我们又看到了熟悉的loadBeanDefinition,就像我们前面对IOC容器的分析一样，这个加载过程在容器refresh()时启动。
    protected void loadBeanDefinitions(DefaultListableBeanFactory beanFactory) throws IOException {
        // Create a new XmlBeanDefinitionReader for the given BeanFactory.
        // 对于XmlWebApplicationContext,当然是使用XmlBeanDefinitionReader来对BeanDefinition信息进行解析
        XmlBeanDefinitionReader beanDefinitionReader = new XmlBeanDefinitionReader(beanFactory);

        // Configure the bean definition reader with this context's
        // resource loading environment.
        // 这里设置ResourceLoader,因为XmlWebApplicationContext是DefaultResource的子类，所以这里同样会使用DefaultResourceLoader来定位BeanDefinition     
        beanDefinitionReader.setResourceLoader(this);
        beanDefinitionReader.setEntityResolver(new ResourceEntityResolver(this));

        // Allow a subclass to provide custom initialization of the reader,
        // then proceed with actually loading the bean definitions.
        initBeanDefinitionReader(beanDefinitionReader);
        //这里使用定义好的XmlBeanDefinitionReader来载入BeanDefinition
        loadBeanDefinitions(beanDefinitionReader);
    }


    protected void initBeanDefinitionReader(XmlBeanDefinitionReader beanDefinitionReader) {
    }


    //如果有多个BeanDefinition的文件定义，需要逐个载入，都是通过reader来完成的，这个初始化过程是由refreshBeanFactory方法来完成的，这里只是负责载入BeanDefinition
    protected void loadBeanDefinitions(XmlBeanDefinitionReader reader) throws BeansException, IOException {
        String[] configLocations = getConfigLocations();
        if (configLocations != null) {
            for (String configLocation : configLocations) {
                reader.loadBeanDefinitions(configLocation);
            }

进入DispatcherServlet和MVC实现

完成了在Web环境中，IoC容器的建立以后，也就是在完成对ContextLoaderListener的初始化以后，Web容器开始初始化DispatcherServlet，接着，会执行DispatcherServlet持有的IoC容器的初始化过程，在这个初始化过程中，一个新的上下文被建立起来，这个DispatcherServlet持有的上下文，被设置为根上下文的子上下文。可以大致认为，根上下文是和Web应用相对应的一个上下文，而DispatcherServlet持有的上下文是和Servlet对应的一个上下文，在一个Web应用中，往往可以容纳多个Servlet存在；与此相对应，对于应用在Web容器中的上下体系，也是很类似的，一个根上下文可以作为许多Servlet上下文的双亲上下文。在DispatcherServlet，我们可以看到对MVC的初始化，是在DispatcherServlet的initStrategies完成的。
在这个初始化完成以后，会在上下文中建立器一个执行器于url的对应关系，这个对应关系可以让在url请求到来的时候，MVC可以检索到相应的控制器来进行处理，如以下代码所示：

    protected Object getHandlerInternal(HttpServletRequest request) throws Exception {
        //这里从request中得到请求的url路径
        String lookupPath = this.urlPathHelper.getLookupPathForRequest(request);
        //这里使用得到的url路径对Handler进行匹配，得到对应的Handler，如果没有对应的Hanlder，返回null，这样默认的Handler会被使用
        Object handler = lookupHandler(lookupPath, request);
        if (handler == null) {
            // We need to care for the default handler directly, since we need to
            // expose the PATH_WITHIN_HANDLER_MAPPING_ATTRIBUTE for it as well.
            Object rawHandler = null;
            if ("/".equals(lookupPath)) {
                rawHandler = getRootHandler();
            }
            if (rawHandler == null) {
                rawHandler = getDefaultHandler();
            }
            if (rawHandler != null) {
                validateHandler(rawHandler, request);
                handler = buildPathExposingHandler(rawHandler, lookupPath, null);
            }
        }
        if (handler != null && logger.isDebugEnabled()) {
            logger.debug("Mapping [" + lookupPath + "] to handler '" + handler + "'");
        }
        else if (handler == null && logger.isTraceEnabled()) {
            logger.trace("No handler mapping found for [" + lookupPath + "]");
        }
        return handler;
    }
   // lookupHandler是根据url路径，启动在handlerMap中对handler的检索，并最终返回handler对象
    protected Object lookupHandler(String urlPath, HttpServletRequest request) throws Exception {
        // Direct match?
        Object handler = this.handlerMap.get(urlPath);
        if (handler != null) {
            validateHandler(handler, request);
            return buildPathExposingHandler(handler, urlPath, null);
        }
        // Pattern match?
        String bestPathMatch = null;
        for (String registeredPath : this.handlerMap.keySet()) {
            if (getPathMatcher().match(registeredPath, urlPath) &&
                    (bestPathMatch == null || bestPathMatch.length() < registeredPath.length())) {
                bestPathMatch = registeredPath;
            }
        }
        if (bestPathMatch != null) {
            handler = this.handlerMap.get(bestPathMatch);
            validateHandler(handler, request);
            String pathWithinMapping = getPathMatcher().extractPathWithinPattern(bestPathMatch, urlPath);
            Map<String, String> uriTemplateVariables =
                    getPathMatcher().extractUriTemplateVariables(bestPathMatch, urlPath);
            return buildPathExposingHandler(handler, pathWithinMapping, uriTemplateVariables);
        }
        // No handler found...
        return null;
    }

最后，我们可以结合在DispatcherServlet中，对请求的分发处理来了解一个url请求到来时，MVC的实现和协同处理过程，如以下代码所示：

    protected void doDispatch(HttpServletRequest request, HttpServletResponse response) throws Exception {
        HttpServletRequest processedRequest = request;
        HandlerExecutionChain mappedHandler = null;
        int interceptorIndex = -1;
        //这里为视图准备好一个ModelAndView，这个ModelAndView持有handler处理请求的结果
        try {
            ModelAndView mv = null;
            boolean errorView = false;
            try {
                processedRequest = checkMultipart(request);
                // Determine handler for the current request.
                // 根据请求得到对应的handler,hander的注册以及getHandler的实现在前面已经分析过
                mappedHandler = getHandler(processedRequest, false);
                if (mappedHandler == null || mappedHandler.getHandler() == null) {
                    noHandlerFound(processedRequest, response);
                    return;
                }
                // Apply preHandle methods of registered interceptors.
                // 调用hander的拦截器，从HandlerExecutionChain中取出Interceptor进行前处理
                HandlerInterceptor[] interceptors = mappedHandler.getInterceptors();
                if (interceptors != null) {
                    for (int i = 0; i < interceptors.length; i++) {
                        HandlerInterceptor interceptor = interceptors[i];
                        if (!interceptor.preHandle(processedRequest, response, mappedHandler.getHandler())) {
                            triggerAfterCompletion(mappedHandler, interceptorIndex, processedRequest, response, null);
                            return;
                        }
                        interceptorIndex = i;
                    }
                }
                // Actually invoke the handler.
                // 这里是实际调用handler的地方，在执行handler之前，用HandlerAdapter先检查一下handler的合法性：是不是按Spring的要求编写的handler
                // handler处理的结果封装到ModelAndView对象，为视图提供展现数据
                HandlerAdapter ha = getHandlerAdapter(mappedHandler.getHandler());
                //这里通过调用HandleAdapter的handle方法，实际上触发对Controller的handleRequest方法的调用
                mv = ha.handle(processedRequest, response, mappedHandler.getHandler());
                // Do we need view name translation?
                if (mv != null && !mv.hasView()) {
                    mv.setViewName(getDefaultViewName(request));
                }
                // Apply postHandle methods of registered interceptors.
                if (interceptors != null) {
                    for (int i = interceptors.length - 1; i >= 0; i--) {
                        HandlerInterceptor interceptor = interceptors[i];
                        interceptor.postHandle(processedRequest, response, mappedHandler.getHandler(), mv);
                    }
                }
            }
            catch (ModelAndViewDefiningException ex) {
                logger.debug("ModelAndViewDefiningException encountered", ex);
                mv = ex.getModelAndView();
            }
            catch (Exception ex) {
                Object handler = (mappedHandler != null ? mappedHandler.getHandler() : null);
                mv = processHandlerException(processedRequest, response, handler, ex);
                errorView = (mv != null);
            }
            // Did the handler return a view to render?
            // 这里使用视图对ModelAndView数据的展现
            if (mv != null && !mv.wasCleared()) {
                render(mv, processedRequest, response);
                if (errorView) {
                    WebUtils.clearErrorRequestAttributes(request);
                }
            }
            else {
                if (logger.isDebugEnabled()) {
                    logger.debug("Null ModelAndView returned to DispatcherServlet with name '" + getServletName() +
                            "': assuming HandlerAdapter completed request handling");
                }
            }
            // Trigger after-completion for successful outcome.
            triggerAfterCompletion(mappedHandler, interceptorIndex, processedRequest, response, null);
        }
        catch (Exception ex) {
            // Trigger after-completion for thrown exception.
            triggerAfterCompletion(mappedHandler, interceptorIndex, processedRequest, response, ex);
            throw ex;
        }
        catch (Error err) {
            ServletException ex = new NestedServletException("Handler processing failed", err);
            // Trigger after-completion for thrown exception.
            triggerAfterCompletion(mappedHandler, interceptorIndex, processedRequest, response, ex);
            throw ex;
        }
        finally {
            // Clean up any resources used by a multipart request.
            if (processedRequest != request) {
                cleanupMultipart(processedRequest);
            }
        }
    }

通过MVC框架，实际上是DispatcherServlet的协调运作，得到了ModelAndView对象作为数据处理结果，最后，DispatcherServlet把获得的模型数据交给特定的视图对象，从而完成这些数据的视图呈现工作，这个视图呈现由视图对象的render方法来完成，毫无疑问，对应于不同的视图对象，render方法会完成不同的视图呈现处理，从而为用户提供丰富的Web UI表现。关于这些不同的视图展现，还可以看到很多很有参考意义的开源软件的灵活使用，限于篇幅，这里就不详细说了。

对Spring MVC框架的个人理解

对Spring作为应用平台的Web应用开发而言，Spring为它们提供了Spring MVC框架，作为一个像struts这样的Web框架的替代；当然，作为应用平台，Spring并不会强制应用对Web框架的选择。但对Web应用开发而言，选择直接使用Spring MVC，可以给应用开发带来许多便利。因为Spring MVC, 毫无疑问，很好的提供了与Web环境中的IoC容器的集成。同时，和其他Web应用一样，使用Spring MVC, 应用只需要专注于处理逻辑和视图呈现的开发（当然这些开发需要符合Spring MVC的开发习惯），在视图呈现部分，Spring MVC同时也集成了许多现有的Web UI实现，比如像Excel, PDF这些文档视图的生成，因为，集成第三方解决方案，实在可以说是Spring的拿手好戏，从这种一致性的开发模式上看，它在很大程度上降低了Web应用开发的门槛。