对sprig框架中控制反转(依赖注入)的理解
2016-09-15 16:27
148 查看
package zj.zgs.dao; public interface UserDao { public void getUser(); } package zj.zgs.dao.impl; import zj.zgs.dao.UserDao; public class UserDaoMySqlImpl implements UserDao { @Override public void getUser() { // TODO Auto-generated method stub System.out.println("MySql获取用户数据"); } } package zj.zgs.dao.impl; import zj.zgs.dao.UserDao; public class UserDaoOracleImpl implements UserDao { @Override public void getUser() { // TODO Auto-generated method stub System.out.println("Oracle获取用户数据"); } } package zj.zgs.service; public interface UserService { public void getUser(); } package zj.zgs.service.impl; import zj.zgs.dao.UserDao; import zj.zgs.service.UserService; public class UserServiceImpl implements UserService{ // private UserDao userDao = new UserDaoMySqlImpl(); // 之前是上面这种做法,由调用者(UserServiceImpl类的实例)创建被调用者 (UserDaoMySqlImpl类的实例),但是这样就存在一个问题,之前我们获取的是 MySql的数据,现在我们增加了一个Oracle的数据库,这样就需要程序能够获取 Oracle类型的数据,为了获取Oracle数据就学要修改之前写的代码,将所有 UserDaoMySqlImpl改为UserDaoOracleImpl,这样维护起来工作量太大,而且 繁琐。 //后来我们就使用下面这种方式,先不关心依赖类的创建,并给调用者提供一个 set方法,用来设置被调用者的类型,这样就将被调用者的创建解耦,被调用者的 类型完全取决于外部的注入。 private UserDao userDao = null; public void setUserDao(UserDao userDao) { this.userDao = userDao; } @Override public void getUser() { // TODO Auto-generated method stub userDao.getUser(); } } package zj.zgs.test; import zj.zgs.dao.impl.UserDaoMySqlImpl; import zj.zgs.dao.impl.UserDaoOracleImpl; import zj.zgs.service.impl.UserServiceImpl; public class Test { public static void main(String[] args) { UserServiceImpl userService = new UserServiceImpl(); userService.setUserDao(new UserDaoMySqlImpl()); userService.getUser(); System.out.println("================================"); userService.setUserDao(new UserDaoOracleImpl()); userService.getUser(); } }
通过上面的案例:
被调用者由原来调用者程序本身创建,变为了程序接收外部的注入。
程序员主要精力集中在于业务实现,而不用关注类创建这复杂的过程。
实现了service和dao的解耦工作。Service层和dao层实现了分离。没有直接依赖关
系。
如果dao的实现发生改变,应用程序本身不需要改变。
依赖注入可以用下面这个例子进行理解。一个人(Java实例,调用者)需要一把斧子(Java实例,被调用者)。
在很久之前,没有做斧子的工厂,商店也没有斧子卖,如果你需要一把斧子,就得自己去打造一把斧子。
后来慢慢发展,有生产斧子的工厂,商店就有斧子卖,如果你现在需要一把斧子,只需要到商店,让导
购员给你一把斧子就OK。而你不用去关心斧子的创建过程,可以把所有的精力放在砍柴上。
哈哈,我是这么理解的,可能说的有些牵强,但是大概意思应该是可以理解的。希望对需要的人有所帮助。
相关文章推荐
- 【转】跟我一起学Spring 3(4)–深入理解IoC(控制反转)和DI(依赖注入)
- 控制反转(IOC) 和依赖注入(DI) 的理解
- 控制反转(IOC) 和依赖注入(DI) 的理解
- 通过laravel理解IoC(控制反转)容器和DI(依赖注入)
- 如何理解spring中的IOC(控制反转)、DI(依赖注入)?
- Spring IoC(控制反转)和DI(依赖注入)的理解
- 依赖注入与控制反转的理解
- 依赖注入(DI)和控制反转(IOC)的理解,写的太好了。
- 依赖注入和控制反转的理解,写的太好了。
- PHP 依赖注入(DI)和控制反转(IoC)简单理解
- Spring IoC(控制反转)和DI(依赖注入)的理解
- Spring 深入理解IOC(控制反转)和DI(依赖注入)
- 控制反转(IOC)/依赖注入(DI)理解
- 依赖注入和控制反转的理解,写的太好了。
- Spring框架(依赖注入)(控制反转)的理解
- 结合配置文件、反射完善控制反转(IoC)、依赖注入(DI) 推荐
- 演进式例解控制反转(IoC)、依赖注入(DI)之一 推荐
- 控制反转(IOC),依赖注入(DI),耦合
- DIP(依赖倒置原则),IoC(控制反转),DI(依赖注入)复习总结
- Spring控制反转(IoC)的理解