前言:上一章节我们介绍了Mybatis的入门,并完成了一个简单入门程序,这一章节,我们主要讲解Mybatis的基础操作,主要是数据的增删改查,重点掌握。
问题一:
这里我们先解释一个新手入门时对mysql和mybatis了解不是很深入的问题。

类比理解:
-
MySQL 就像是 厨房和仓库。
-
它负责实际存储食材(数据),并按照订单(SQL)进行烹饪(查询/处理)。
-
它有自己的规则(SQL语法、存储引擎)。
-
-
MyBatis 就像是 服务员和传菜系统。
-
你(程序员)告诉服务员要点什么菜(调用Java方法)。
-
服务员将你的点菜单(方法调用)翻译成厨房能听懂的指令(生成/执行SQL),然后从厨房取菜,并把做好的菜装盘,以你方便食用的方式端给你(将查询结果封装成Java对象)。
-
没有厨房(MySQL),服务员(MyBatis)毫无用处。没有服务员,你直接和后厨沟通会很麻烦
-
更深入的技术视角:它们如何协同工作?
在一个典型的Java Web应用中(如 Spring Boot + MyBatis + MySQL),数据流向是这样的:
应用程序层:你的业务代码调用一个UserService的方法,例如getUserById(1)。
MyBatis层:
-
UserService会调用UserMapper接口的对应方法。
-
MyBatis根据UserMapper接口的配置(XML文件或注解),找到对应的SQL语句:SELECT * FROM user WHERE id = #{id}。
-
MyBatis通过连接池从数据库获取一个连接。
-
将Java参数 1 安全地设置到SQL语句中(防止SQL注入)。
-
通过JDBC驱动,将完整的SQL发送给MySQL数据库。
MySQL层:
-
MySQL服务器接收并解析SQL语句。
-
在存储引擎(如InnoDB)中查询user表,找到id=1的数据行。
-
将查询结果集通过JDBC连接返回给MyBatis。
MyBatis层(再次):
-
接收到原始的结果集(ResultSet)。
-
根据映射配置,自动将结果集的每一行数据转换为一个User对象(属性名与列名匹配或按规则映射)。
-
将封装好的User对象返回给应用程序层。
应用程序层:UserService拿到了User对象,继续后续业务逻辑。
对比

问题二:
其次就是我们在idea数据库中配置的项目数据源,mybatis@localhost,这里在数据库里添加的mybatis并不是一个数据库,
-
mybatis@localhost = 你的"数据库望远镜"
-
只在开发时用
-
帮你观察数据库内容
-
不影响实际运行
-
-
项目的MyBatis配置 = 应用程序的"数据库引擎"
-
程序运行时用
-
驱动整个应用的数据访问
-
必须正确配置
-
所以不要被名字迷惑,mybatis@localhost只是IDEA为了帮你更好地开发MyBatis项目而提供的一个开发辅助工具,不是MyBatis框架本身的一部分。
Mybatis的环境准备:
具体操作见上一篇的入门程序,一摸一样。
Mybatis的增上改查对比Mysql的增删改查:
什么时候用原生SQL?
一次性脚本:数据迁移、报表生成
数据库管理:DBA操作、性能调优
简单原型:快速验证想法
学习阶段:理解SQL原理
什么时候用MyBatis?
企业级应用:需要长期维护
团队协作:需要统一规范
复杂业务:动态SQL、关联查询
安全要求:防止SQL注入
数据库迁移可能:需要抽象层
MyBatis的"复杂"是一种"聪明的复杂":
-
前期成本:配置确实比直接写SQL复杂
-
长期收益:维护性、安全性、扩展性大幅提升
-
团队价值:规范统一,新人上手快
-
工程价值:SQL集中管理,便于优化和重构
就像装修房子:
-
直接SQL = 自己买材料、自己施工
-
简单直接,马上能住但水电布线乱七八糟,以后维修麻烦
-
-
MyBatis = 请专业装修公司
-
前期要设计、沟通、付钱但水电网络布局合理,以后加装智能家居很方便
-
对于现代软件开发来说,MyBatis的这种"复杂"是值得的,它把混乱的JDBC操作变成了有组织日志输出 可以在application.properties中,打开mybatis的日志,并指定输出到控制台。 #指定mybatis输出日志的位置,输出控制台 mybatis.configuration.log-impl=org.apache.ibatis.logging.stdout.StdOutlmpl的、可维护的代码结构。当你的项目从"个人小工具"成长为"企业级系统"时,你就会感谢MyBatis带来的秩序。
删除:
动态删除需求
接口类中
使用到了mybatis中的参数占位符#{}; 执行SQL时,会将#{}替换为?,生成预编译SQL,会自 动设置参数值。 使用时机:参数传递,都使用#{}
${} 拼接SQL。直接将参数拼接在SQL语句中,存在SQL注 入问题。 使用时机:如果对表名、列表进行动态设置时使用。

单元测试中:

日志输出 可以在application.properties中,打开mybatis的日志,并指定输出到控制台。 #指定mybatis输出日志的位置,输出控制台 mybatis.configuration.log-impl=org.apache.ibatis.logging.stdout.StdOutlmpl
预编译SQL 优势 性能更高 更安全(防止SQL注入)
简单的理解预编译,普通的mysql执行时,就像是家里面炒菜,现炒现做,一步一步,不能跳步;
而预编译sql,就像是有一个炒菜模板,每次做饭都能直接用,大大提高了效率。
新增:
问题3
Console和MyBatis冲突吗? 不冲突,是互补关系! 开发阶段:用Console设计、测试SQL 编码阶段:把验证过的SQL写到MyBatisXML中.·运行阶段:MyBatis自动执行,Console用于监控
在Console中设计和测试SQL(草稿)
把验证正确的SQL复制到MyBatis XML中(定稿)
在Java中调用Mapper方法(使用)
需要调试时,再用Console查看数据状态
所以,Console不是多余的,而是MyBatis开发的好帮手,它们各司其职,共同帮助高效开发。
接口类:

单元测试类:

主键返回:
描述:在数据添加成功后,需要获取插入数据库数据的主键。 如:添加套餐数据时,还需要维护套餐菜品关系表数据。
更新:
接口类:

测试类:

查询:
接口类

测试类:

数据封装 实体类属性名和数据库表查询返回的字段名一致,mybatis会自动封装。 如果实体类属性名和数据库表查询返回的字段名不一致,不能自动封装。
解决方法:
1.给字段起别名,使得字段名和属性名一样。
2.手动映射封装,通过@Results

3.开启mybatis驼峰命名自动映射开关
mybatis.configuration.map-underscore-to-camel-case=true
条件查询:
接口类

测试类:

改善
因为‘’里面不能有?,所以不能使用参数占位符,我们一开始修改成¥{},但是会有sql注入安全,之后我们采取cocat,一举两得。

网硕互联帮助中心




评论前必须登录!
注册