spring配置功能分析以及设计

AOP的功能分析及设计_踩踩踩从踩的博客-CSDN博客IOC及DI功能分析与设计_踩踩踩从踩的博客-CSDN博客

前言

本篇文章会从spring的配置部分分析，为什么要用配置，以及用什么样的配置方式，以及配置工作流程 怎么样的工作流程来解决加载类，提供bean定义， 定义xml annotaion配置进行完善 ioc 对于bean定义的加载，完成配置加载器。

配置分析

为什么需要配置的方式

• 实用简单、改动灵活
• 不需要改动代码

利用配置文件 可以解决很多的问题，不修改代码 ，这在开发过程中，为什么要配置就是这样来的。配置在很多场合 非常重要，但是把配置多了也太复杂，才有了约定大于配置的概念。

 如果程序没有配置文件，一定是没有人用的。而且越大的框架  配置文件是越多的，就算springboot采用约定大于配置的方式，但是还是不能避免内部给了很多配置。

这些都需要调整的。 用配置是非常好的，不用改代码是最直观的表现。

配置的基本流程

能使用的方式配置方式也是最常见的：

xml和注解的方式。

各自的配置方式工作过程：

 需要定义一套配置或者注解的方式，不同的应用标记是不一样的。一定是要定义标准，用户使用标记配置或者注解具体的业务功能， 告诉框架bean定义放置的地方，加载bean定义的配置文件或者注解，框架解析配置文件 或者类。 解析完了得到bean定义 ，并且注册到bean工厂中。

 整个配置方式的过程，

配置工作过程

这里需要定义什么标记，或者注解，一定要参照着bean创建的内容，才能定义什么标签或者注解。

而bean定义需要哪些标签，包括 构造参数等等。

 

包括id  class  初始化方法  销毁方法。我们需要为此定义一个DTD或者XSD文档

在spring中

 定义好语法这些。

 需要定义些什么注解？

利用component中添加属性 就可以 做 指定类等方法。通用的，包括初始化销毁的方法等。

 指定好beanname进行 比较。

 配置的过程中，指定配置好的xml, 可以在创建applicationcontext对象时就去指定好 注解或者xml  的位置。

而在 这部分 在那里去配置 加载解析。

 如果放到 beanfactory中 会导致 beanfactory非常沉重的。

方框中所做的事情是解析bean配置，向beanFactory注册bean定义。它不是beanFactory的事情。

应单独定义接口、类来完成这件事  

这里 就应入了 applicationcontext这个概念。

ApplicationContext用来完成Bean配置解析

 

Xml配置方式的实现

Xml源可能是多个

完成的工作：加载、解析、创建、注册

注解配置方式的实现

扫描的包多个：list

完成工作：扫描、获取、创建、注册

将BeanFactory抽出来放到父类中

这两部分有相同的部分，注册。 都要用到beanfactory中去，BeanFactory/BeanDefinitionRegistry

/**
 * ApplicationContext抽象实现类
 */
public abstract class AbstractApplicationContext implements ApplicationContext {
	// 用组合的方式持有beanFactory，完成beanFactory接口的方法
	protected BeanFactory beanFactory;

	public AbstractApplicationContext() {
		super();
		// 还可以通过构造函数传递一个beanFactory的实现
		this.beanFactory = new PreBuildBeanFactory();
	}
	public AbstractApplicationContext(BeanFactory factory) {
		super();
		// 还可以通过构造函数传递一个beanFactory的实现
		this.beanFactory = factory;
	}

	@Override
	public Object getBean(String name) throws Exception {
		return beanFactory.getBean(name);
	}

	@Override
	public void registerBeanPostProcessor(BeanPostProcessor bpp) {
		this.beanFactory.registerBeanPostProcessor(bpp);
	}

}

 用户要使用我们的框架需要知道哪些接口、类？

1. 指定配置相关，xml、annotation

2. 获取bean相关，BeanFactory

需要context接口。

外观模式应用：让用户只需要知道ApplicationContext及其子类是否对用户更简单？如何完成？

让他持有起来。 把两个接口

提供一个新的外观（外观模式应用）

ApplicationContext继承自BeanFactory，两个接口合并到一起

把beanfactory包起来。对于用户来说只需要 获取context ， 外观模式的具体的实现。

配置的方式，配置加载 相关接口的设置。

实现配置过程

XML文件来源处理

 我们希望能加载不同来源的xml,向解析提供一致的使用接口。如何做？如何设计接口、类？

而且他们的加载方式是不一样的。

加载的结果统一抽象成InputStream

 这里在定义时，获得inputstream . 来自各种不同的资源。

这里我们定义不同的Resource类对应不同来源的xml资源，谁去负责分辨创建它们的对象？

因为用户给定时是一个个的字符串（这对他们是最简单的方式）。

需要加载器，用户使用字符串定义资源，需要一个资源加载器分辨不同的资源

分辨字符串，创建对应的Resource对象的工作就是加载，由ApplicationContext来做

/**
 * 用来构建整个应用环境的接口，用来完成Bean配置解析。<br/>
 * 1. 为减少用户对框架类接口的依赖，扩展BeanFactory接口，这样
 * Bean配置和Bean的获取都能够通过ApplicationContext接口来完成。<br/>
 * 2. 配置资源有xml和annotation两种方式。存在xml和annotation的两种类型的子类实现 <br/>
 * 3. Bean配置解析首先需要加载，故实现了配置资源Resource的加载接口ResourceLoader。
 */
public interface ApplicationContext extends ResourceLoader, BeanFactory {

}

 

需要应用工厂模式的味道：

根据不同的字符串前缀创建不同的资源对象

 

并且在不同的资源进行加载。

/**
 * 配置资源加载接口。<br/>
 * 不同的配置方式，有不同的加载过程，故需要抽象一个接口来拥抱变化的部分。
 * 虽然加载方式不同，但是返回的资源结果是一样的Resource。
 */
public interface ResourceLoader {
	/**
	 * 加载资源
	 * @param location
	 * @return
	 * @throws IOException
	 */
	Resource getResource(String location) throws IOException;
}

注解如何扫描 

定义一个资源路径匹配行为 ，来扫描如果要扫描的是com.dn下所有service包下的类， 

 

所以这里需要添加接口去处理。

扫到了指定包下的所有class文件，需要到类名。

 最终扫描到的是class文件，File即可

 

 

 也是一样的操作，  这里 去封装出来。

 在扫描注册类中。

主要获取bean定义的注解 加载和扫描 的输出。

要做的就是

配置的最终结果

XML和注解最终的输出都是Resource，这个Resource如何解析成BeanDefinition