Spring-IOC与AOP是解决什么问题的？

1.1 框架需求分析

1.1.1 问题描述：编码依赖问题

在程序中要分层，且层与层相互调用就会存在依赖, 下面代码同学们应该不会陌生:

publicclass StudentAction {

* 采用new的方式创建业务逻辑层,为硬编码的方式

* 这种方式缺乏灵活性,后期维护则需要编译class文件之后覆盖原来的class文件

* 这种方式也体现不出面向接口编程的好处

private StudentService studentService = new StudentServiceimpl();

private Student student;

public Student getStudent() {

returnstudent;

}

publicvoid setStudent(Student student) {

this.student = student;

}

public String save() {

studentService.save(student);

return"success";

}

同样在业务逻辑层调用数据访问层中,也会出现如下问题：

publicclass StudentServiceimpl implements StudentService {

* 如果底层切换的数据库,则数据访问层也要切换, 但是目前new 之后不方便修改

* */

private StudentDao studentDao=new StudentDaoImpl();

publicvoid save(Student student) {

studentDao.save(student);

}

以上代码是有问题的，即在控制层中依赖了具体的业务逻辑层, 在业务逻辑层中依赖了具体的数据访问层. 这样就和具体的实现类耦合在了一起，也没有发挥面向接口编程的作用. 如果要更换（比如要换成StudentDaoOracleImpl），就需要修改源代码，但是项目很多模块都需要同时修改,这样会非常麻烦. 而且修改完毕之后还要编译成class文件,覆盖原来的文件. 不利于项目的后期维护, 而且项目与项目之间的依赖隐藏在了代码中.也不适合全局把握正个项目, 因此维护性和二次开发比较麻烦

1.1.2 解决方案1:工厂模式

可以使用抽象工厂, 让StudentDao StudentService的实现在在工厂中生成，而工厂可以根据配置文件的指定类型,来创建不同的对象, 而且工厂本身一般是不变的. 从而降低了对可以变的业务逻辑类的依赖, 接近的软件的设计目标”高内聚,低耦合”

控制层à抽象工厂à业务逻辑层

publicclass StudentAction {

* 依赖具体的对象,改为依赖工厂, 而工厂创建的路径来自具体的配置文件,所以灵活性大大提高

* 必须要声明为接口类型,否则工厂没有任何意义(面向接口编程)

* */

private StudentService studentService=(StudentService)BeanFactory.getBean("studentService");

private Student student;

public Student getStudent() {

returnstudent;

}

publicvoid setStudent(Student student) {

this.student = student;

}

public String save() {

studentService.save(student);

return"success";

}

业务逻辑层à抽象工厂à数据访问层

publicclass StudentServiceImpl implements StudentService {

* 依赖工厂,降低耦合度,可以根据配置灵活修改创建的对象

* */

private StudentDao studentDao=(StudentDao)BeanFactory.getBean("studentDao");

publicvoid save(Student student) {

studentDao.save(student);

}

以上代码就是通过抽象工厂来实现层与层之间的解耦，这种情况下如果想要更新别外一个实现类，只需要修改配置文件就可以了, 注意这里只是降低了层与层之间的复杂度, 并没有让耦合消失, 实际上层与层是不可能没有耦合的,我们学框架的目的就是要找到变的部分,然后用配置文件来配置这样修改的时候修改配置文件就OK了, 不需要修改代码本身

但是有时候有些类创建的时候需要单例模式, 有的则需要多个实例、还有不同的类在创建的时候有些类需要初始化操作, 有些又不需要初始化数据…..这又怎么办呢？那就要再完善一下这个工厂类了, 或者多创建一些工厂了. 让工厂可以处理这些问题, 但是我们自己实现起来就复杂了

1.1.3 解决方案2: IOC依赖注入

所谓依赖注入就是指：在运行期,由外部配置文件动态地将本身所依赖对象通过set方法注入到组件中,我们只需要用即可,而不需要在去管理对象的创建和销毁, 我们期望的代码应该是如下：

publicclass StudentAction {

// 只要符合接口类型,就可以注入进来,这样我们都不需要依赖工厂

private StudentService studentService=null;

// 通过set方式,在运行期间注入

publicvoid setStudentService(StudentService studentService) {

this.studentService = studentService;

}

private Student student;

public Student getStudent() {

returnstudent;

}

publicvoid setStudent(Student student) {

this.student = student;

}

public String save() {

studentService.save(student);

return"success";

}

或者如下代码：

publicclass StudentServiceImpl implements StudentService {

// 只要符合接口类型,就可以注入进来,这样我们都不需要依赖工厂

private StudentDao studentDao=null;

publicvoid save(Student student) {

studentDao.save(student);

}

1.1.4 问题描述: 编程式事务

publicvoid save(Student student){

Session session=HibernateSessionFactory.getSession();

// 手动控制的事务称为编程时事务

try {

session.getTransaction().begin();

session.save(student);

session.getTransaction().commit();

} catch (HibernateException e) {

e.printStackTrace();

session.getTransaction().rollback();

}finally{

HibernateSessionFactory.closeSession();

}

以上代码是有问题的, 红色的部分, 每次只要有数据修改操作的时候则都要编写, 更重要的是这些代码与方法的功能本身又没有紧密的联系.而且基本每个模块都有, 重复的代码大大降低了我们的效率和增加了维护的成本,

1.1.5 解决方案1: 代理模式

// 创建一个代理类,来完成Session事务的提交、回滚

publicclass SessionProxy implements Session {

private Session session = null;

public SessionProxy(Session session) {

this.session = session;

}

publicvoid begin() {

session.getTransaction().begin();

}

publicvoid rollback() {

session.getTransaction().rollback();

}

publicvoid save(Student student) {

try {

this.begin();

session.save(student);

} catch (Exception e) {

this.rollback();

} finally {

this.commit();

}

publicvoid commit() {

session.getTransaction().commit();

}

数据访问层代码修改如下:

publicvoid save(Student student){

// HibernateSessionFactory返回的是session的代理

SessionProxy sessionProxy=HibernateSessionFactory.getSession();

// 代理的save中调用了 begin commit 或者rollback

sessionProxy.save(student);

}

代理缺点：不灵活,以后修改了接口, 代理类也要维护. 而且代理的类型受到接口的制约, 但是我们的事务基本所有的业务逻辑模块都有. 所以此方法不易推广

1.1.6 解决方案2: AOP声明式事务