为啥SpringBoot更多普遍采用Controller+Service接口层+ServiceImpl接口实现层 |
您所在的位置：网站首页 › service层和serviceimpl › 为啥SpringBoot更多普遍采用Controller+Service接口层+ServiceImpl接口实现层 |
|
为啥SpringBoot更多普遍采用Controller+Service接口层+ServiceImpl接口实现层？
为解决移植性问题而产生的套路 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(); } } |
今日新闻 |
推荐新闻 |
| CopyRight 2018-2019 办公设备维修网 版权所有 豫ICP备15022753号-3 |