为解决移植性问题而产生的套路
2005年以前的大多数项目都是直接在业务处理层的Service类中嵌入JDBC代码，这就使得这个Service类与数据库紧藕合，在换一种数据库的情况下，就要修改Service类中的sql。 根据软件设计的开闭原则，软件应该对修改关闭、对扩展开放。 因此，那时聪明的程序员就把这个Service类设计成一个接口，使控制层只依赖这个接口，于是就有了controller+service+serviceImpl；这样，当某天这个应用要跑在其它数据库上时，就而只需要增加一个serviceImpl类。 这就是service+serviceImpl套路产生的背景。
如果该Service有多个实现类，如何设置注入哪个ServiceImpl类
接口
public interface HumanService {
public String name();
}
接口实现类
@Service("teacherService")
public class TeacherServiceImpl implements HumanService {
@Override
public String name() {
System.out.println("teacher");
return "teacher";
}
}
@Service("doctorService")
public class DoctorServiceImpl implements HumanService {
@Override
public String name() {
System.out.println("doctor");
return "doctor";
}
}
控制器
@RestController
public class HumanController {
// @Resource(name="doctorService")
@Autowired
@Qualifier("teacherService")
private HumanService humanService;
@RequestMapping("/name")
public String name(){
return humanService.name();
}
}