记一次MyBatis的错误
错误信息:java.lang.StackOverflowError
关于这个错误的深度解析，大家可以参考这篇博文，比较详细:https://blog.csdn.net/zc375039901/article/details/79179465\
先说说这个错误，我是怎么发生的？我的这个错误与上面我推荐的该错误原因深度解析没有多大的关系，大家可以适当了解了解。
简单的说，这是一个低级错误，特别对于"码农"头衔的大多数开发者而言。
习惯了惯性思维，习惯的复制粘贴，习惯了那套编写业务逻辑层的方式。
贴代码讲示例:
错误代码:
@Service public class SysModuleServiceImpl extends ServiceImpl<SysModuleDao, SysModule> implements SysModuleService { @Autowired private SysModuleService sysModuleService; @Override public List<SysModule> queryModuleListInfo(Map<String, Object> map) { // TODO Auto-generated method stub return sysModuleService.queryModuleListInfo(map); } @Override public int queryModuleCountInfo(Map<String, Object> map) { // TODO Auto-generated method stub return sysModuleService.queryModuleCountInfo(map); } }
这是我一时疏忽，这样写了，其实也不能说是一时疏忽，只能说是思维定势导致的。
开发者们一定不能思维定势，对于思维定势的开发者们，业界有这样一句名言，做五年的开发，相当于一年而已或者是开发多年，还是在那一套章法上循环往复。
不多说大道理了，关于上面的代码为什么不能这么写，为什么是错的,下面我将进行解答。
首先来说，@Service这个注解，大家应该不陌生了，特别是对于Java开发者们。
与这个注解并列的有@Reponsitory,@Component，@Controller,这些对于奋战一线的开发者们，早已眼熟而详了。
关于上面我为什么会犯这个错误？因为我忽略了依赖注入。
通常情况下，业务逻辑层直接与数据访问层交互，而Dao层，早已通过MyBatis动态扫描，注入了也就是在对应的spring-mybatis.xml文件配置了Bean。
当然了，这里要提一点，之所以不用MyBatis非动态扫描的方式，最大的原因是难以维护，不方便管理，因为如果采用这种方式，每个对应的Dao，我都要专门写一个bean进行管理，这样非常不好。特别对于业务需求时常变化，甚至以后功能扩展，代码重构都会带来很大的麻烦。而采用动态扫描的方式，则只要在Spring-MyBatis.xml配置对应的如下所示即可，这里我用的是MyBatis Plus，MyBatis Plus和MyBatis同Spring整合，基本上是没有区别的，除了一些特殊的插件和其他优化配置之外。
<!-- Spring整合Mybatis，更多查看文档：http://mp.baomidou.com -->
<bean id="sqlSessionFactory" class="com.baomidou.mybatisplus.spring.MybatisSqlSessionFactoryBean">
<property name="dataSource" ref="dataSource"/>
<!-- 自动扫描Mapping.xml文件 -->
<property name="mapperLocations" value="classpath:mybatis/system/*.xml"/>
<property name="configLocation" value="classpath:mybatis/mybatis-config.xml"/>
<property name="typeAliasesPackage" value="com.blog.entity"/>
<property name="plugins">
<array>
<!-- 分页插件配置 -->
<bean id="paginationInterceptor" class="com.baomidou.mybatisplus.plugins.PaginationInterceptor">
</bean>
</array>
</property>
<!-- 全局配置注入 -->
<property name="globalConfig" ref="globalConfig" />
</bean>
<bean id="globalConfig" class="com.baomidou.mybatisplus.entity.GlobalConfiguration">
<!--
AUTO->`0`("数据库ID自增")
INPUT->`1`(用户输入ID")
ID_WORKER->`2`("全局唯一ID")
UUID->`3`("全局唯一ID")
-->
<property name="idType" value="2" />
</bean>
<!-- MyBatis 动态扫描 -->
<bean class="org.mybatis.spring.mapper.MapperScannerConfigurer">
<property name="basePackage" value="com.blog.daor"/>
</bean>
关键一行就是动态扫描这一行，还有就是对应的xml配置文件，上面和下面结合使Dao接口与xml文件中的sql进行绑定。
业务逻辑层是基于数据访问层的，如果直接业务逻辑层按照我文章开头那样的错误代码写法，是无法访问Dao层的。
另外大家要知道一点，层与层之间是双向关系，数据访问层依赖于数据库，数据库如果有什么异常，是会报错的，业务逻辑层依赖于数据访问层，控制层也就是接口层或者路由层，因为这里主要是处理前台请求的，并根据对应的逻辑返回对应的数据或者某种提示信息等等。
正确代码如下:
@Service public class SysModuleServiceImpl extends ServiceImpl<SysModuleDao, SysModule> implements SysModuleService { @Autowired private SysModuleDao sysModuleDao; @Override public List<SysModule> queryModuleListInfo(Map<String, Object> map) { // TODO Auto-generated method stub return sysModuleDao.queryModuleListInfo(map); } @Override public int queryModuleCountInfo(Map<String, Object> map) { // TODO Auto-generated method stub return sysModuleDao.queryModuleCountInfo(map); } }
这里还要提一下，为什么要有业务逻辑层，简单的说，业务逻辑层主要是为了复用数据访问层，实际业务是非常复杂的，需要整合多个数据访问层来达到实现业务的目的，比如拿智能门锁来说，我需要知道门锁编码是否存在，之前是否批量导入，根据我们的业务，与我们合作商，购买我们的门锁，通常购买一般以批次来衡量，比如他们购买了我们100把门锁，我们在后台通过一个Excel数据记录对应的门锁编号和其他相关数据，将其录入到我们的数据表中(批量导入),然后对方使用我们的后台管理系统进行安装，虽然我们导入了但是尚未激活，门锁有一个对应的状态，默认为0(尚未安装的或尚未激活的意思)。
当他们安装时，首先需要判断安装门锁编码是否存在，另外他们用于住宿方面，酒店编号和房间编号是否存在(这里使用我们对应的智能酒店管理系统与智能门锁后台系统进行关联，还有就是网关，判断网关是否安装，而且网关涉及到我们另外的数据表，为了使门锁与网关结合，我们需要编写一个方法，该方法涉及两张表的业务方面，所以这里就需要业务逻辑层，这里我想表达的意思是，业务逻辑层就是为了更好的处理业务和复用业务，以此来达到构建一个可扩展性好，可维护性好，稳定性好的web系统。
小结:这里我想告诉大家的是，不要忽视任何一个错误以及对于编程人员而言，是用脑来思考编程如何做的更好，而不是慢慢的变为一个重复性的体力劳动。当然了，博主我目前也没有完全做到，所以需要不断的学习和实际中不断的反思总结，以此来达到做最优秀的程序员和写一手优雅的代码目的。
