DB-schema与领域模型不匹配时spring-data-jdbc对比JdbcTemplate有何价值

哪怕你当前没有数据库schema管控权、表结构和领域模型存在你提到的两类差异，使用Spring Data JDBC相比原生JdbcTemplate依然能拿到非常实在的收益——你担心的查询派生、开箱即用的全自动映射只是Spring Data JDBC特性集的一小部分，根本不存在“结构不匹配就完全没法用”的非黑即白的情况。

这些能力不管你的表和模型差多少，都能直接用上：

• 省掉所有JDBC底层样板代码：不用手动管连接、Statement、ResultSet的资源关闭，不用自己把JDBC原生的checked异常转成Spring统一的运行时数据访问异常，不用自己处理不同数据库类型和Java类型的参数适配，这些都是框架底层封装好的基础能力，和映射逻辑没关系。
• 映射规则一次配置到处复用：针对你说的「扁平列要映射嵌套值对象」的场景，简单的列名不匹配直接用@Embedded+@Column配对应关系就行，复杂的字段转换只要写一次Converter注册到Spring上下文，之后所有CRUD、自定义查询返回对应聚合/值对象的时候都会自动套用规则，不用像裸用JdbcTemplate那样，每个查询都要重复写RowMapper，或者自己攒一堆零散的映射工具类还要手动维护调用。
• 多表聚合自动组装：针对你说的「星型模型字段散在多张表」的场景，你只需要在Repository方法上用@Query写好关联查询的SQL，Spring Data JDBC会自动按聚合根ID对结果集去重，自动完成聚合根、嵌套值对象、关联实体的实例化和拼装，完全不用你自己遍历ResultSet判断当前行属于哪个聚合、手动往对象里塞属性，这部分至少能省掉70%的多表查询映射代码。
• 通用能力开箱即用：哪怕你全量写自定义查询，只要映射规则配好，基础的按主键CRUD、乐观锁、审计字段自动填充（创建/更新时间、操作人）、分页排序参数统一处理这些能力都能直接用，不需要自己重复造轮子。
• 代码层抽象统一：所有Repository都遵循Spring Data的统一接口规范，不管是内置方法还是自己写的查询方法，业务层调用的规则完全一致，不会出现裸用JdbcTemplate时DAO层方法名乱起、参数传递规则不统一的问题。

你提到的查询派生（Query Derivation）、零配置自动映射确实会因为结构差异打折扣，但不是完全用不了：

• 只要是聚合根对应主表上的字段，简单过滤条件的查询派生照样能正常跑，只有涉及跨表过滤、嵌套值对象特殊逻辑的查询才需要自己写@Query
• 就算完全不用查询派生，你写自定义SQL的体验和在JdbcTemplate里写SQL没有任何区别，但依然能享受到前面说的自动映射、结果集组装、参数绑定的便利，不会比用JdbcTemplate多写一行代码。

如果你所有的查询都是动态拼接的超复杂多表查询、没有明确的聚合边界、每次查询返回的都是结构完全不同的自定义投影，Spring Data JDBC的聚合装配优势会被削弱，但就算是这种场景，它提供的参数绑定、异常转译、类型转换机制依然比裸用JdbcTemplate顺手。

内容的提问来源于stack exchange，提问作者Christian Nockemann