spring配置功能分析以及设计

Posted 2022-01-10 踩踩踩从踩

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了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;