【Spring】核心机制：IOC与DI深度解析-EW帮帮网

三层架构包括：

表示层（Presentation Layer）：负责用户交互和界面展示，如Controller接收HTTP请求

业务逻辑层（Business Logic Layer）：处理核心业务逻辑，如Service层

数据访问层（Data Access Layer）：负责与数据库交互，如DAO/Repository

// 传统三层架构示例（无Spring）
public class UserController {
    private UserService userService = new UserServiceImpl();
    
    public void doSomething() {
        userService.process();
    }
}

public class UserServiceImpl implements UserService {
    private UserRepository userRepository = new UserRepositoryImpl();
    
    public void process() {
        userRepository.query();
    }
}

public class UserRepositoryImpl implements UserRepository {
    public void query() {
        // 数据库操作
    }
}

这种架构的主要问题是紧耦合——每一层都直接实例化下一层的对象，导致难以维护和测试。

紧耦合：修改实现类需改动多处代码

难以测试：依赖对象无法轻松替换（如Mock测试）

对象生命周期复杂：难以统一管理资源释放

这正是Spring要解决的问题。Spring通过IOC容器管理对象，让各层组件通过依赖注入的方式协作。

2.2Spring核心思想（IOC与AOP）

Spring通过IoC容器实现控制权反转：

容器掌控对象生命周期：创建、配置、组装、销毁

依赖关系由容器注入：对象被动接收依赖

配置元数据驱动：XML或注解定义对象关系

// Spring容器管理下的对象获取
ApplicationContext context = new ClassPathXmlApplicationContext("beans.xml");
UserService userService = context.getBean("userService", UserService.class);

工作原理：

读取配置元数据（XML/注解）

实例化Bean并存储于容器

解析依赖关系完成注入

返回完全装配的可使用对象

接下来简单介绍AOP：

在业务系统中，存在大量横切关注点（Cross-Cutting Concerns）：

日志记录

事务管理

权限校验

性能监控

这些功能散布在各个模块中，导致：

代码重复：相同逻辑多次出现

维护困难：修改需改动多处

业务逻辑污染：核心代码掺杂辅助功能

于是就有了AOP（面向切面编程）

概念：

切面（Aspect）：封装横切功能的模块（如日志模块）

连接点（Join Point）：程序执行的可插入点（方法调用、异常抛出）

切点（Pointcut）：定义哪些连接点会被拦截

通知（Advice）：切面在特定连接点的动作

2.3两类注解：组件标识与配置

2.3.1五大类注解

Spring通过注解来标识和管理Bean，以下是五种核心的类级别注解：

2.3.1.1Controller

用于表示层，处理HTTP请求和响应。

@Controller
@RequestMapping("/user")
public class UserController {
    @Autowired
    private UserService userService;
    
    @GetMapping("/info")
    public String getUserInfo(Model model) {
        model.addAttribute("user", userService.getUser());
        return "userInfo";
    }
}

角色定位
@Controller声明这是一个MVC控制器，专门处理HTTP请求

路由映射
@RequestMapping定义基础路径，@GetMapping指定具体端点（/user/info）

依赖管理
@Autowired自动注入Service层组件，实现控制反转（IoC）

请求处理流程

接收请求参数（隐式Model对象）

调用Service获取业务数据

数据绑定到模型（model.addAttribute）

返回视图名称（"userInfo"）

设计本质
实现了MVC模式的Controller层，通过注解驱动开发，达成：
✔️ 请求路由 ✔️ 依赖解耦 ✔️ 视图控制

2.3.1.2Service

用于业务逻辑层，标识服务类。

@Service
public class UserServiceImpl implements UserService {
    @Autowired
    private UserRepository userRepository;
    
    @Override
    public User getUser() {
        return userRepository.findById(1L);
    }
}

服务标识
@Service标记为业务服务组件，Spring会自动管理其生命周期

分层架构
实现UserService接口，面向接口编程，实现业务逻辑层

数据访问
@Autowired注入Repository层组件，遵循依赖倒置原则

业务封装
在服务方法中：

整合数据访问操作

实现业务规则

处理事务边界（可加@Transactional）

设计本质
作为业务逻辑的中枢：
✔️ 解耦控制器与数据访问层
✔️ 集中业务规则实现
✔️ 提供可重用的服务方法

2.3.1.3Repository

用于数据访问层，标识DAO/Repository类。

@Repository
public class UserRepositoryImpl implements UserRepository {
    @Override
    public User findById(Long id) {
        // 实际数据库操作
        return new User(id, "张三");
    }
}

持久层标识
@Repository标记为数据访问组件，Spring会自动进行异常转换和事务管理

接口契约
实现UserRepository接口，遵循"面向接口编程"原则

职责聚焦
专注实现：

数据库CRUD操作

数据访问逻辑

SQL/NoQL交互

设计本质
作为数据访问的统一门户：
✔️ 隔离业务层与具体数据库实现
✔️ 集中管理数据访问逻辑
✔️ 提供标准化的数据操作方法

2.3.1.4Configuration

用于配置类，替代传统的XML配置。

@Configuration
public class AppConfig {
    @Bean
    public DataSource dataSource() {
        return new DruidDataSource();
    }
}

配置标识
@Configuration声明这是Spring配置类，替代传统XML配置方式

Bean管理
@Bean注解的方法用于向容器注册组件（这里是Druid数据源）

核心作用

集中管理第三方组件

自定义Bean的初始化过程

解决无法用@Component注解的类（如第三方库）

设计本质
作为IoC容器的装配车间：
✔️ 解耦组件创建逻辑
✔️ 统一管理复杂对象初始化
✔️ 支持条件化配置（可配合@Profile/@Conditional）

2.3.1.5Component

通用注解，当组件不属于以上几类时使用。

@Component
public class CustomComponent {
    // 自定义组件
}

注解	应用场景	对应层级
@Controller	MVC控制器	表现层
@Service	业务逻辑组件	业务层
@Repository	数据访问组件	数据层
@Configuration	配置类定义	配置层
@Component	通用组件	任意层级

五大注解本质区别：从功能上讲，这五个注解本质上是相同的，都可以将类标识为Spring管理的Bean。它们的区别主要在于语义层面，帮助开发者更好地组织代码结构。

2.3.2方法注解（Bean）

定义：

@Bean是Spring框架中用于显式声明单个Bean的方法级别注解，通常用在@Configuration类中，用于向IoC容器注册组件。

@Configuration
public class AppConfig {
    @Bean
    public UserService userService() {
        return new UserServiceImpl();
    }
    
    @Bean(name = "dataSource")
    public DataSource createDataSource() {
        // 创建并返回DataSource
    }
}

工作流程：

解析@Configuration类

发现@Bean方法

执行方法获取Bean实例

根据Bean名称注册到容器

使用案例：

@Configuration
public class AppConfig {
    
    @Bean
    public DataSource dataSource() {
        DruidDataSource ds = new DruidDataSource();
        ds.setUrl("jdbc:mysql://localhost:3306/mydb");
        ds.setUsername("root");
        ds.setPassword("123456");
        return ds;
    }
}

命名规则：

默认名称：方法名（如dataSource）

自定义名称：@Bean("myDataSource")

@Bean与@Component的区别：

特性 @Bean @Component

作用对象方法类

控制粒度单个Bean的精细控制类级别的自动注册

适用场景第三方库组件的注册自定义类的注册

初始化控制可在方法中自定义初始化逻辑依赖构造函数/Setter

特性	@Bean	@Component
作用对象	方法	类
控制粒度	单个Bean的精细控制	类级别的自动注册
适用场景	第三方库组件的注册	自定义类的注册
初始化控制	可在方法中自定义初始化逻辑	依赖构造函数/Setter

2.4扫描路径

Spring组件扫描（Component Scanning）是框架自动发现和注册Bean的机制，通过扫描指定包路径下的类，识别带有特定注解（如@Component、@Service等）的类，并将它们注册到IoC容器中。

启动注解：@ComponentScan

目标注解：@Component及其衍生注解（@Controller、@Service、@Repository等）

@Configuration
@ComponentScan("com.example")
public class AppConfig {
    // 扫描com.example包及其子包
}

2.4.1显式声明扫描路径

// 单个包扫描
@ComponentScan("com.example.service")

// 多包扫描
@ComponentScan({"com.example.service", "com.example.controller"})

// 通过类定位包
@ComponentScan(basePackageClasses = {UserService.class, OrderService.class})

2.4.2默认扫描行为

Spring Boot项目：默认扫描主类所在包及其子包

非Boot项目：需要显式配置@ComponentScan

com
└── example
    ├── config    // 通常放配置类
    ├── service   // 业务服务层
    ├── dao       // 数据访问层
    └── web       // 控制器层

2.5依赖注入

2.5.1属性注入

@Service
public class UserService {
    @Autowired  // 直接在字段上注解
    private UserRepository userRepository;
}

优点：

代码简洁，减少样板代码

适合快速原型开发

缺点：

破坏封装性（字段变为非final）

难以进行单元测试（必须通过反射注入）

可能导致循环依赖

隐藏了依赖关系

2.5.2构造方法注入

@Service
public class UserService {
    private final UserRepository userRepository;
    
    // Spring 4.3+可以省略@Autowired
    public UserService(UserRepository userRepository) {
        this.userRepository = userRepository;
    }
}

优点：

明确声明必需依赖

依赖项可设为final（不可变）

易于单元测试（直接通过构造器传入mock对象）

避免循环依赖问题

Spring官方推荐方式

缺点：

当依赖较多时构造函数参数列表较长

Spring官方推荐说明：

"Spring团队通常建议使用构造器注入，因为它允许将应用程序组件实现为不可变对象，并确保所需的依赖项不为空。"

2.5.3setter方法注入

@Service
public class UserService {
    private UserRepository userRepository;
    
    @Autowired
    public void setUserRepository(UserRepository userRepository) {
        this.userRepository = userRepository;
    }
}

优点：

灵活性高，可以重新配置依赖

适合可选依赖

符合JavaBean规范

缺点：

对象可能在部分初始化的状态下被使用

不能保证依赖项的不变性

2.5.4三种注入优缺点分析

特性	属性注入	构造器注入	Setter注入
代码简洁性	⭐⭐⭐⭐⭐	⭐⭐⭐	⭐⭐⭐⭐
不可变性	❌	✅	❌
单元测试便利性	❌	✅	⭐⭐⭐
循环依赖处理	❌	❌	✅
Spring推荐度	不推荐	强烈推荐	条件推荐
依赖明确性	隐式	显式	显式
适用场景	快速原型开发	必需依赖	可选依赖

2.5.5@Autowired存在问题

当Spring容器中存在多个相同类型的Bean时，直接使用@Autowired会导致异常。下面详细介绍三种主流解决方案：

2.5.5.1@Primary注解

通过设置主候选Bean来解决歧义，当存在多个同类型Bean时，优先选择标记@Primary的那个。

// 方案一：标记主Bean
@Repository
@Primary  // 当有多个UserRepository时优先选择此实现
public class JdbcUserRepository implements UserRepository {
    // JDBC实现...
}

@Repository
public class JpaUserRepository implements UserRepository {
    // JPA实现...
}

// 使用端无需特殊处理
@Service
public class UserService {
    @Autowired  // 自动注入JdbcUserRepository
    private UserRepository userRepository;
}

优点：

使用简单，无侵入性

集中管理主要实现

减少重复配置

局限：

只能解决"默认选择"问题

无法灵活切换不同实现

2.5.5.2@Qualifier注解

通过明确指定Bean名称来消除歧义，实现精确注入。

// 方案二：定义限定标识
@Repository("jdbcRepo")  // 显式命名Bean
public class JdbcUserRepository implements UserRepository {
    // JDBC实现...
}

@Repository("jpaRepo")
public class JpaUserRepository implements UserRepository {
    // JPA实现...
}

// 使用端明确指定
@Service
public class UserService {
    @Autowired
    @Qualifier("jdbcRepo")  // 按名称精确匹配
    private UserRepository userRepository;
}

优点：

精确控制注入目标

支持运行时动态切换

可扩展性强（支持自定义限定符）

局限：

增加了配置复杂度

需要记忆Bean名称

2.5.5.3@Resource注解

使用@Resource注解，按名称进行装配。

// 方案三：使用JSR-250标准注解
@Repository("jdbcUserRepo")  // 定义Bean名称
public class JdbcUserRepository implements UserRepository {}

@Repository("jpaUserRepo")
public class JpaUserRepository implements UserRepository {}

// 使用JSR-250的@Resource
@Service
public class UserService {
    @Resource(name = "jdbcUserRepo")  // 按名称匹配
    private UserRepository userRepository;
}

特性	@Autowired	@Resource
标准	Spring特有	JSR-250标准
默认行为	按类型匹配	按名称匹配
名称指定	需要配合@Qualifier	直接支持name属性
required属性	支持	不支持

优点：

符合Java标准，减少框架耦合

语义明确（显式按名称注入）

与CDI（Contexts and Dependency Injection）兼容

局限：

功能比@Autowired简单（缺少required配置等）

在纯Spring环境中优势不明显

3.小结

今天的分享到这里就结束了，喜欢的小伙伴点点赞点点关注，需要所有的源代码可以去我的gitee上就可以啦~你的支持就是对我最大的鼓励，大家加油！

爱吃烤鸡翅的酸菜鱼 (crjs-hao) - Gitee.comhttps://gitee.com/crjs-hao另外最后的最后，欢迎大家加入我的社区哦，初创社区难免经验不足，请大家多多包涵，也欢迎大家前来多多交流。

爱吃烤鸡翅的酸菜鱼社区-CSDN社区云https://bbs.csdn.net/forums/aaa1f71356f6475db42ea9ea09a392bc?spm=1001.2014.3001.6682

【Spring】核心机制：IOC与DI深度解析

1.前言

2.正文

2.1三层架构