Spring-ioc初体验

在之前的Javaweb中,我们通常要实现dao层,service层,Servlet层。

其中,dao层直接对数据库进行操作,service层在内部创建了dao的对象,代替我们去调用dao层去操作数据库,实现了业务的分离。

但是,有一个弊端

我们先实现一个样例

public interface UserDao {
    void getUser();
}
public class UserDaoImpl implements UserDao{
    @Override
    public void getUser() {
        System.out.println("默认输出用户");
    }
}
public interface UserService {
    void getUser();
}
public class UserServiceImpl implements UserService{
    UserDao userDao=new UserDaoImpl();//dao层对象
    @Override
    public void getUser() {
        userDao.getUser();
    }
}

尽管看起来比较正常,但是如果我们这时候要更改需求呢?要求从mysql数据库中取出用户数据,那么我们就需要再实现一个dao类,然后到service中修改创建的对象,这就是问题所在了。编程的思想应该是扩展,扩展的同事不应该修改源代码。

Spring-ioc初体验

Spring-ioc初体验 如果项目非常大,更改一个需求就需要去更改源代码的话,是一个非常危险的事情,很可能项目会崩溃,而且工程量也非常大。

这时候还有没有更好的解决方法呢?

我们可以使用多态,动态的从外部传入一个dao对象,这是一个革命性的变化。

Spring-ioc初体验

 我可以直接从外部传入。

原来的主体是service的实现类,现在,主体已经可以是用户了。 

因为需求的变化,已经是由用户传入的dao对象决定的了,而不是service的实现类内部决定的。

service本来就是与用户交互的,这时候就是由用户决定。

Spring-ioc初体验

 

 这就是控制反转的思想:

之前,程序是主动创建对象,控制权在程序员手上

使用了set注入以后,程序不在具有主动性,而是变成了被动的接受对象

这种思想,从本质上解决了问题,我们程序员不用再去管理对象的创建了。系统的耦合度也大大降低了,可以更加专注的在业务的实现上了。这就是ioc的原型

上一篇:spring介绍


下一篇:IoC模式(依赖、依赖倒置、依赖注入、控制反转)