转：有多少人在滥用 service+serviceImpl，又有多少人在误用myBatis

被滥用的service+serviceImpl

    JAVA大概是从2003年开始流行，我也是从那时开始学习JAVA。在这十多年中，相关技术推陈出新，我切身感受到这些变化。虽然很多程序员不断追随新技术，但未必领悟到这些变化的推动因素。     最近我看到不少新开工的项目，仍然大量采用 “service+serviceImpl、dao+daoImpl” 的代码结构，说真的，我有点痛心，似乎这种做法是理所当然的，似乎这成了一个技术套路。 今天，我想说的是，这样做是不合理的、没有意义的、过时的。

从代码混战到分层分块

    由于java的流行和互联网的普及，企业网站、企业应用的开发开始从C/S转为B/S, 所以从那时起做好一个WEB应用很重要。     刚开始，也即2002~2003年，大家都是采用jsp+javabean+jdbc的方式，也不知道怎么分层，有的干脆把所有代码放在jsp中。 后来大家发现这样没法玩了，系统根本没法维护，也不安全，于是就有了MVC这样的架构模式。     MVC的理念挽救了这种局面，并且，运用该理念的模块化开发框架Struts出现了。MVC和Struts的广泛使用，使得开发WEB应用在业界达成了一个共识，那就是WEB应用基本可分为表现层、控制层、业务处理层。

    到2004年，对WEB应用进行分层、分模块已是程序员的常识。 但是，有追求有讲究的企业发现了新的问题，那就是如何使自己的应用或产品既可以跑在mysql上，也可以跑在oracle上。 这个问题对程序员来说，就是如何编写业务处理层，使之易于移植到其它数据库。

为解决移植性问题而产生的套路

    2005年以前的大多数项目都是直接在业务处理层的Service类中嵌入JDBC代码，这就使得这个Service类与数据库紧藕合，在换一种数据库的情况下，就要修改Service类中的sql。 根据软件设计的开闭原则，软件应该对修改关闭、对扩展开放。 因此，那时聪明的程序员就把这个Service类设计成一个接口，使控制层只依赖这个接口，于是就有了controller+service+serviceImpl；这样，当某天这个应用要跑在其它数据库上时，就而只需要增加一个serviceImpl类。 这就是service+serviceImpl套路产生的背景。

    在那时service+serviceImpl并非解决这个问题的唯一方案，还有部分项目，他们的团队更有想法，他们把与数据库打交道的代码从service类中提取出来，成为单独的“数据访问层”（也称为“持久层”），于是形成了这样的层次结构 controller+service+dao+daoImpl。 了不起！这样对不同的数据库，可以有对应的daoImpl。 相比前面那种方案，而扩展一个daoImpl比扩展一个serviceImpl省事多了。

数据访问层的解决方案或框架

    由于传统的JDBC代码，繁锁费事，因此不少人或团队尝试将这些代码封装起来，以使程序员不用再编写操作数据库连接、游标、数据集这样的逻辑。这样的工具通常以O/RMapping的思想作为基础，也称为O/RMapping框架。 2006年，hibernate从多种ORMapping框架中脱颖而出，很多项目中的 serviceImpl类开始采用hibernate来实现。hibernate强大，是把双刃剑，易上手但用好难、扩展性好但效率一般。(这也是我曾自研easydb的原因，代码： https://github.com/HuQingmiao/easydb)

    2010年，myBatis诞生，2012年开始流行并讯速得到广泛认可。由于myBatis本身是采用xml文件实现的，因此能极好地融入到项目中，只需要把service+dao+daoImpl 中的daoImpl类去掉，改由其mapp.xml实现即可，即service+dao+mapper.xml。 然而，还有很多人在用myBatis的项目中，采用service+serviceImpl+ dao+daoImpl+ mapper.xml, 真的是浪费青春。所以，我说很多人在误用myBatis。