mybatis plus,mybatisplus

mybatis plus，mybatisplus？

在MyBatis Plus中，实体类的字段不必须和表中的字段一一对应。这是因为MyBatis Plus使用了基于注解的方式来映射实体类和数据表，在实体类中可以使用注解来定义字段与表字段的映射关系，例如通过`@TableField`、`@TableId`、`@TableLogic`等注解来定义字段属性。

通过这些注解可以灵活地自定义实体类字段与表中字段的映射关系，包括字段名不一致、字段类型不一致等情况。

实体类字段与表中字段的映射关系的定义可以在Mapper中通过注解的方式实现，也可以在全局配置文件中进行配置。所以，MyBatis Plus中的实体类字段不必须在表中存在，可以按需定义。

mybatisplus？

如果出现 mybatisplus 读取不到 xml 的情况，可能是以下原因：

1. 配置文件不正确：检查 mybatisplus 的配置文件是否正确配置，尤其是 mapper 接口的配置和 xml 文件的路径配置。

2. XML 文件位置不正确：确认 XML 文件所在的位置是否正确，是否在指定的路径下。

3. XML 文件格式不正确：确认 XML 文件的格式是否正确，是否符合 mybatisplus 的要求。

4. 命名空间不匹配：检查 mapper 接口的命名空间是否与 XML 文件中的命名空间匹配。

5. 依赖注入不正确：检查 mybatisplus 是否正确依赖注入，是否缺少必要的依赖。

如果以上方法都无法解决问题，可以尝试查看 mybatisplus 的文档或者向官方社区寻求帮助。

mybatis中用insert数据怎么返回主键？

主键是自动赋值在对象中的。比如对象User,属性id为主键，name，age User user = new User()

; user.setName("test")

; user.setAge(16); 调用mybatis的insert（user）；返回值是1，该条记录的主键通过user.getId();即可获龋

为什么还要用mybatis？

这个问题需要真实去使用过，在使用的过程中会发现各自框架的痛点，当你寻找解决方案的时候，你会看其它框架有没有解决这个问题，这样你就会领悟到另一个框架的优势了。

分享一个真实的实战经历：

项目刚开始使用原始JDBC方式操作数据库，自己手动建表不说，手动组装对象太痛苦，表字段和对象的关系映射写一堆代码，这时候就会想如果有个框架能自动把表和对象关系自动映射，并且能够封装好使用方法，在初始化时还能自动建表就更好了。

查找方案时发现了SpringDataJpa，仿佛打开了新世界的大门，原来通过写SQL查询再转成对象的增删改查都不用写了，表字段和对象的映射也不需要手工写代码去匹配可，直接使用，而且可以开启初始化时自动创建数据库表。原来需要消耗时间的数据库操作代码现在完全不用写了，简单的条件查询，直接调用封装的方法，快到起飞。但是随着业务数据的不断增多，要查询的条件也越来越复杂，查询时效越来越慢，渐渐对查询性能也有了要求。然后就想，在这样的使用便利上，如果有能便于优化数据库查询性能的解决方案就好了。

再次找解决方案，发现了MyBatis，感觉发现了另一个新世界。虽然，它不能直接把表和对象的关系映射自动封装好，但是它可以直接把操作结果映射成需要的对象，只需要建立对应的数据对象DTO就行，并且多表关联查询、复杂条件查询都可以写SQL解决，最重要的是SQL和逻辑代码分析，维护也很方便，SQL优化交给专业的DBA就行，再次好用到起飞。

突然有一天，公司强制要求数据库从oracle换成MySQL，发现Mybatis因为都是写的纯SQL，原来的SQL语法是oracle的，现在都要改，太依赖数据库了，不便于换数据源。这时想起了不依赖数据源的JPA。

总结一下个人看法：

JPA使用完全面向对象的的设计思想，一个表就是一个对象，所有的操作直接操作对象就行，方便、快捷，也不需要关注底层数据源问题，但是表之间的关系复杂了、查询复杂了，这样的操作不是它的强项。

Mybatis是半面向对象、半面向SQL，SQL与逻辑代码分离，查询结果映射成对象，所有操作上层是对象，下层用SQL，数据查询优化上更加实用，因为是写原生SQL，所以换数据源可能麻烦。

还是业内的那句老话，没有绝对“银弹”，只有适合当前业务发展需要的技术。