【问题】传统的javaweb存在的问题——耦合度偏高。
【注1】首先需要引入【XxxService和XxxDao的区别与联系】
要注意到，使用javaweb、ssm（ssh）及springboot等框架都要回归到 业务 本身，Spring就是面向接口编程。service层主要在于具体的业务内容，dao层对应实体类在数据库中的每张表。而展示层（View）调用控制层（Controller），控制层（Controller）调用业务层（Service），业务层（Service）调用数据（访问）层（Dao）。
这样的结构实现了分层，达到了解耦的目的。当我们的（需求即）业务发生改变时（增加、删除、修改），某一层的代码更改不影响其他层的，也就实现了“高解耦低内聚”中的高解耦。
这里体现了主要是new一个bookDao的实现类这里耦合了，业务层中不应该有具体的对象，最多只能有其引用。所以这里应该只留一个引用。而这里的工作将交给下面要复习的核心概念来完成。
【核心概念1】
在【注1】中提到，不能（自己）new一个对象，应该交给“外部”来提供对象。
这里的“外部”指的是IoC（控制反转，Inversion of Control），即创建对象的控制权由程序转交给外部。
而Spring的伟大之处就在于它实现了控制反转的思想。具体表现为：Spring提供了一个叫IoC容器的容器，用于充当IoC思想中的“外部”。
IoC容器负责对象的创建、初始化等一系列工作，被创建或管理的对象在IoC容器（或Spring）中统称为Bean。
因此，容器中的service和dao都是一个个的bean。
【注2】虽然IoC容器中已有service，但是要知道service还需要依赖dao运行。
【核心概念2】
因此，在IoC容器中，需要形成service对dao的依赖关系。
这里就需要提到——DI（依赖注入，Dependency Injection），即在容器中建立bean与bean之间的依赖关系的整个过程。
【最终效果】
这样，就实现了前面说的【问题】“耦合度高”，通过【核心概念1】和【核心概念2】中提到的IoC和DI，实现了“充分耦合”的目标。
使用对象时，不仅可以直接从IoC容器中获取（bean），并且获取到的bean都已经绑定好了所有的依赖关系。
【具体实现1】XML版的IoC入门案例：
【注3】IoC容器会管理service与dao（bean）。
【注4】被管理的对象（bean）是通过配置告诉IoC容器的。
【注5】被管理的对象交给IoC容器后，通过接口获取到IoC容器。
【注6】得到IoC容器后，通过接口方法获取bean。
1、导入Spring坐标（pom中，spring-context）
2、定义spring管理的类（接口）——XxxService及其实现类XxxServiceImpl
3、创建spring的配置文件，配置对应类为spring管理的bean（bean定义时id属性在同一上下文中不能重复）
4、初始化IoC容器（或：Spring容器、Spring核心容器），通过容器获取bean
【具体实现2】XML版的DI入门案例：
【注7】基于IoC管理bean
【注8】service中使用new形式创建的dao对象不会再保留，因为有了DI不会再采用这样耦合度高的方式了
【注9】service中需要的dao对象通过提供的方法进入到service中
【注10】service和dao之间的关系也是通过配置进行描述的
1、
改为：
2、并提供setter方法：
3、并在spring的配置文件中加入server和dao的关系：
（service标签中的dao的ref属性必须与dao的id一致）
【报错1】如果缺乏了这一关系的配置，会出现空指针异常：
【报错2】Bean定义异常：
这说明，要不就是在配置bean的时候出错了，要不就是在获取bean的时候出错了。
【bean标签】
bean标签中，name属性为bean的别名，多个别名可用",",";"," "分隔。
bean标签中，scope属性表示【1】默认为单例，singleton【2】修改为prototype，表示非单例，即每次生成的bean都不是同一个。
【注11】bean之所以默认为单例，是因为spring容器中管理的bean都是单例的，即可复用的对象。其中，适合交给容器管理的bean：【1】表现层对象view【2】业务层对象service【3】数据层对象dao【4】工具对象utils；不适合~的bean：封装实体的域对象
475
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
