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中修改创建的对象，这就是问题所在了。编程的思想应该是扩展，扩展的同事不应该修改源代码。

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

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

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

 我可以直接从外部传入。

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

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

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

 

 这就是控制反转的思想：

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

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

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