为解决移植性问题而产生的套路
2005年以前的大多数项目都是直接在业务处理层的Service类中嵌入JDBC代码，这就使得这个Service类与数据库紧藕合，在换一种数据库的情况下，就要修改Service类中的sql。 根据软件设计的开闭原则，软件应该对修改关闭、对扩展开放。 因此，那时聪明的程序员就把这个Service类设计成一个接口，使控制层只依赖这个接口，于是就有了controller+service+serviceImpl；这样，当某天这个应用要跑在其它数据库上时，就而只需要增加一个serviceImpl类。 这就是service+serviceImpl套路产生的背景。
为什么有这样的区别呢？我举个例子，
当我在定义接口时，会有一个权限验证的方法，
但是并不是所有的请求都回进入这个方法（比如登录接口）；
此时，可将请求经过的路线分为两类：1（进入过权限验证），2（没有进入过权限验证）；
但这两条路都是从同一个端口进入后台的。
假设都是从/oatuth/login
类比
service层=service接口+serviceImpl实现类；
service接口层就是端口，serviceImpl实现类里不同的方法就是dosomething1，和dosomething2.乃至dosomething3。
以上为举例。
当使用
service层=service接口+serviceImpl实现类——的形式后，
业务逻辑将会更便于扩展。
但缺点就是：多了一层——service接口；
凡事都有得必有失；
但我们可以因地制宜，选择最合适自己项目的。
如果该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(); } }
