如上图，我在mapper层编写了一个list方法用于实现动态sql。
1.导入使用xml文件的mybatis依赖。
2.配置文件的修改
.properties
.yml
-
mybatis.mapper-locations=classpath:mapper/*.xml：- 这个配置项指定了 MyBatis 映射器 XML 文件的位置。
- 值
classpath:mapper/*.xml表示 MyBatis 应该在类路径的mapper目录中查找映射器 XML 文件。 - 这些 XML 文件定义了 SQL 语句和结果映射。
-
mybatis.type-aliases-package=com.example.big_event.pojo：- 这个配置项指定了 MyBatis 应该在哪个包中查找并注册为类型别名的 Java 类。
- 类型别名是可以在 MyBatis XML 配置文件中使用的简短名称，代替完全限定的类名。
- 例如，如果你有一个
com.example.big_event.pojo.User类，你可以在映射器 XML 文件中使用User来代替完整的类名。
namespace：填写mapper层的类。
id：mapper层你所编写的动态sql方法名
resultType：实体属性类
注意：xml文件名称要跟mapper层的文件名称保持一致。
语句填写好后就实现了xml文件的基本配置了。
在使用动态SQL时，有些开发者选择将SQL语句直接写在方法上，使用依赖注解的方法来实现，而另一些开发者则选择使用XML文件来编写动态SQL。两者各有优缺点，选择哪种方式主要取决于项目需求、团队习惯和代码维护的考虑。下面将详细探讨这两种方法的优缺点。
使用依赖注解的方法编写动态SQL
优点：
- 简洁明了：将SQL语句直接写在方法上，代码集中在一个地方，便于查看和理解。
- 方便调试：在调试时，可以直接看到SQL语句，方便快速定位问题。
- 代码一致性：使用依赖注解的方式，可以让SQL和业务逻辑保持在同一个地方，增强代码的可读性和一致性。
缺点：
- 复杂的SQL处理困难：对于复杂的动态SQL，使用注解会使方法变得非常复杂和难以维护。
- 代码膨胀：如果SQL语句较长或较复杂，方法体会变得臃肿，不利于代码的清晰和简洁。
- 注解的限制：注解方式在某些情况下可能受到限制，不能灵活地处理所有动态SQL需求。
使用XML文件实现动态SQL
优点：
- 灵活性高：XML文件支持复杂的动态SQL生成，使用标签（如
<if>、<choose>、<foreach>等）可以灵活地拼接SQL语句。 - 代码清晰：将SQL与Java代码分离，可以使代码更清晰，业务逻辑和SQL语句各自独立，便于维护。
- 易于修改：修改SQL语句时，不需要重新编译Java代码，只需要修改XML文件即可，方便部署和维护。
- 重用性强：可以将常用的SQL片段抽取成公用的XML片段，在多个地方重用，减少代码重复。
缺点：
- 调试困难：由于SQL语句不直接在Java代码中，调试时需要额外的步骤查看生成的SQL语句。
- 学习成本：需要学习和掌握XML标签的用法，对于新手来说，可能需要一些学习成本。
- 配置文件管理：大量的XML文件可能导致配置文件的管理和维护变得复杂。
总结
使用哪种方法主要取决于项目的具体需求和团队的偏好：
- 项目规模较小，SQL语句简单：可以考虑使用依赖注解的方法，简洁直观。
- 项目规模较大，SQL语句复杂：建议使用XML文件，便于SQL的灵活拼接和独立维护。
