@Select("SELECT * FROM users WHERE id = #{id}") User findById(Long id);
2.1 开发效率对比分析
注解在开发阶段的速度优势相当明显。编写一个查询方法时，所有代码都集中在同一个位置——SQL语句、参数映射、返回类型一目了然。不用在Java文件和XML文件之间反复切换，也不用担心文件路径配置错误导致映射失效。
我经历过一个项目迁移，从XML配置转向注解开发。同样的功能模块，开发时间缩短了约30%。特别是快速迭代阶段，新增一个查询接口几乎就是几分钟的事情。注解让代码变得自包含，每个接口方法都是完整的业务单元。
但注解并非在所有场景都更快。复杂动态SQL还是XML更擅长，那种多条件组合查询，用注解写起来会变得冗长难读。曾经尝试用注解实现一个包含5个可选条件的搜索，结果方法上的注解堆了十几行，反而失去了简洁性。
2.2 维护性对比分析
维护性是个有趣的话题。短期来看，注解的维护体验很好——修改SQL时直接定位到方法，不用在多个文件间跳转。团队新成员上手也快，代码逻辑集中在一个地方，理解起来不费劲。
长期项目又是另一回事。XML配置虽然分散，但所有SQL语句都集中管理，方便DBA参与优化。我记得有个项目运行两年后需要做SQL性能调优，XML版本直接给DBA看mapper文件就行，注解版本却需要他们理解Java代码。
版本控制时的冲突处理也值得考虑。XML配置通常团队中只有少数人修改，冲突概率低。注解分散在各个接口中，多人开发时容易在同一个文件上产生冲突。这个差异在大型团队中特别明显。
2.3 适用场景对比分析
选择注解还是XML，很大程度上取决于项目特点。小型项目、快速原型开发，注解的优势很明显。代码量少，部署简单，团队规模小的时候，注解带来的开发效率提升很可观。
中型项目可能需要混合使用。简单的CRUD用注解，复杂的多表关联、动态SQL用XML。这种混合策略在实践中很常见，既能享受注解的便利，又不失去XML处理复杂场景的能力。
大型企业级项目往往偏向XML配置。SQL语句集中管理，便于DBA审核优化。业务逻辑和数据处理逻辑分离，架构更清晰。团队分工明确时，后端开发写Java代码，DBA负责SQL优化，这种协作模式用XML更合适。
微服务架构下，注解可能重新获得青睐。每个服务代码量不大，团队规模小，快速迭代的需求强烈。这时候注解的简洁性和开发效率就变得很有吸引力。
说到底，没有绝对的优劣，只有适合与否。理解各自的特点，根据项目实际情况做选择，这才是最重要的。
3.1 CRUD操作注解实现
基础的增删改查用注解实现起来特别直观。@Select、@Insert、@Update、@Delete这四个注解覆盖了大部分日常开发需求。直接在方法上标注，SQL语句紧随其后，代码阅读起来很流畅。
我最近重构的一个用户管理模块，把所有基础CRUD都改成了注解方式。查询用户信息就是简单的一个@Select，插入新用户用@Insert，配合@Options获取自增主键。代码量减少了近一半，而且逻辑集中在一个文件里，维护起来特别顺手。
参数传递在注解中也很灵活。使用@Param明确指定参数名，或者在SQL中直接用#{字段名}引用。对于实体对象参数，直接使用属性名就能完成映射。这种简洁性让新手开发者能快速上手。
返回结果映射有多种选择。简单的单表查询，直接定义返回类型就行。需要自定义映射时，@Results和@Result注解组合使用，可以精确控制每个字段的映射关系。虽然配置稍多，但避免了额外的XML文件。
3.2 复杂查询注解应用
复杂查询场景下，注解依然能胜任，只是需要一些技巧。多表关联查询使用@Results配置映射关系，虽然代码量会比XML多，但所有信息都在一个地方，调试时不用来回切换文件。
动态SQL在注解中通过 Java 实战面试站 版权所有
适用《知识共享 署名-非商业性使用-相同方式共享 3.0》协议-中文版
页面加载时长：0.135 秒 数据库查询：21 次 占用内存：4.52 MB
Copyright Java 实战面试站 .Some Rights Reserved. 沪ICP备2023033053号 网站地图