- 博客(66)
- 收藏
- 关注
RSS订阅原创 MyBatis 的真相，可能跟你听说的完全不一样
上一篇我们分析了主流持久层方案的共同病灶：在开发者和 SQL 之间插入翻译层，翻译不产生新能力，只产生成本。同时也指出：开发者的重复劳动（判空、拼接、参数收集）确实需要收口。SQL 的语义（关键字、运算符、表达式）坚决不翻译，保证 100% 可见；SQL 的劳动（判空、拼接、收集、对齐）全部抽象，保证 0% 重复。数据库访问 = 准备 SQL、准备参数、拿回结果。SQL 语义不翻译，SQL 劳动全收口。问题不是被解决的，是没有发生的条件。
2026-09-27 09:24:43
230
原创 别再伺候框架了：一个条件类看懂 SimpleDAO 的全部哲学——回归 SQL 本质的三件事
数据库访问 = 准备 SQL、准备参数、拿回结果。SQL 语义坚决不翻译，SQL 劳动全部收口。框架越薄，天花板越高；中间层越少，问题越少。问题不是被解决的，是没有发生的条件。核心框架源码：https://gitee.com/gao_zhenzhong/simple-dao管理系统完整底座（RBAC 权限、鉴权、前后端脚手架）：https://gitee.com/gao_zhenzhong/simple-dao-starter。
2026-09-26 15:17:22
301
原创 用最简洁的方式拼字符串：MyBatis 能做到吗？
MyBatis 能否实现如 SimpleDAO 般简洁的字符串拼接？答案是：能，但代价高昂。虽然可通过 XML 的 <if>、<foreach> 实现动态条件，但需大量冗余配置、运行时校验、手动绑定参数，且难以调试。而 SimpleDAO 以 Java 代码直接拼接，一行一个 add()，空值自动跳过，参数自动收集，无 XML、无接口绑定、编译期即检错，复杂场景（如 CTE）也更清晰。本质差异在于：MyBatis 是“配置驱动”，而 SimpleDAO 是“代码驱动”。简洁性上，后者完胜。
2026-09-11 15:52:16
586
原创 Spring JDBC Ultra：凭什么敢说自己是 MyBatis 终结者？
<think>我们根据要求生成一个≤150字的文章摘要。摘要应概括文章核心内容：对比ORM/MyBatis/Spring JDBC，提出使用工具类补全Spring JDBC动态SQL，覆盖MyBatis动态标签，宣称是终结者。需简洁。</think>Spring JDBC Ultra仅用150行工具类覆盖MyBatis全部动态标签：无XML/OGNL，add()一行表达等值、范围、IN、LIKE、子查询，自动判空转义。批判ORM多表臃肿、MyBatis语法转移；以最短执行链、完全可控SQL补全Spring
2026-09-08 14:47:01
350
原创 我为什么把 MyBatis 从项目中删了？
<think>我们只需生成摘要，无需评论。摘要≤150字。基于内容，描述方案特点和优势。尽量简洁。</think>基于Spring JDBC的持久层方案SimpleDAO，将代码量减少60%。核心设计：动态条件拼接简化为一行，不封装SQL与Spring异常，保持完全控制力；三层架构（BaseSql/BaseDao/BaseCondition）各司其职；独创单表联表同一套API、参数自动判空、参数合并等。继承空类即可获得完整CRUD，联表查询同样简洁。
2026-09-06 21:30:14
597
原创 被流量捧上神坛的框架，与被遗忘的正确答案
<think>我们根据用户要求，基于提供的长文生成≤150字的摘要。需要抓住核心论点：用“是否消灭工作”标准评估数据访问框架，批判JPA和MyBatis，提出SQL-First范式（三层架构、双不封装、双重复用）。摘要要简洁，不超过150字。注意字数限制。可以概述为：以“是否消灭工作”为尺，指出JPA翻译稳定层、MyBatis只是语法转移且零模仿，提出SQL-First范式：稳定层不翻译、动态层工程化，用BaseCondition/BaseDao/BaseSql三件套实现单表联表统一API、屏蔽判空等。需控
2026-09-05 13:59:36
595
原创 MyBatis 被捧上神坛，是一场认知扭曲
<think>好的，用户要求根据提供的长文生成一篇不超过150字的文章摘要。摘要需要高度浓缩核心观点，抓住作者的核心论断。 这篇文章的核心论点是：MyBatis被过度推崇是一种认知扭曲，在“简洁性”维度上它不优于Spring JDBC + 工具类。作者给出了16条论据，核心是：XML动态SQL本质是降级封装、安全靠的是JDBC参数化、DBA可直接改SQL是伪前提、ORM时代话术错用、生态繁荣等于补坑生态、黑盒税导致调试困难、异常类爆炸等。最终结论是MyBatis在简洁性上任何场景都不优于Spring JDB
2026-09-04 17:58:15
697
原创 Spring JDBC Ultra：一个被遗忘的生态位，正在重新定义持久层框架
框架单表对象化关系对象化业务代码浓度SQL 可见性✅ 做得好❌ 稀烂 (<1/10)~40%❌ 黑盒MyBatis⚠️ 靠 Plus❌ 联表退回 XML~30%⚠️ 标签切割JOOQ⚠️ 不自动✅ 能做~50%⚠️ DSL 翻译❌ 完全手动✅ 能做100%✅ 100% 透明✅ 做得最好✅ 做得最好≈100%✅ 100% 透明没有任何一个框架在“单表对象化”和“关系对象化”两个维度上同时做得好。
2026-09-03 10:56:18
541
原创 MyBatis全面解构：彻底祛魅，撕开持久层框架的营销滤镜
<think>我们只需要生成摘要。根据要求“根据以下内容，生成≤150字的文章摘要”，需输出不超过150字。内容围绕MyBatis解构，核心是区分营销与设计，指出XML拼接SQL错配、生态补丁、底层依赖Spring-JDBC，并展示Spring-JDBC Ultra案例。摘要应简洁概括。注意字数。</think>本文从技术设计维度解构MyBatis，指出其XML拼接SQL属历史错配，动态SQL实为语法转移，扩展依赖补丁插件且底层仍基于Spring-JDBC基建。通过对比跨语言实践及Spring-JDBC U
2026-09-02 09:25:27
469
原创 ⚡Spring JDBC 完整体系 · 第 10 集 · 手搓 `BaseCondition`
步骤做了什么驱动力①纯粹的 POJO 条件类承载查询参数②把拼装逻辑塞进条件类拼装逻辑必须有载体③抽取add三合一方法每个字段都在重复判空和拼接④明确划分“专用”和“共用”基础设施在每个类里完全一样⑤抽离基类共用部分与具体业务无关，必须复用一句话总结的诞生不是一次突发灵感，而是被每一阶段的实际问题倒逼出来的必然结果。从最简单的 POJO 出发，一步步解决重复判空、重复基础设施、重复代码的问题，最终收敛为一个可复用的条件基类。
2026-09-01 12:06:27
528
原创 ⚡Spring JDBC 完整体系 · 第 9 集 | 封装 list 方法 · 泛型初探
<think>我们只需要从给定内容生成一篇≤150字的摘要。内容是关于Spring JDBC封装list方法、泛型初探的。需要概括核心：项目背景、痛点（每次new RowMapper）、解决方案（BaseDao封装list泛型方法，传入SQL和Class，内部用BeanPropertyRowMapper）。注意字数限制，抓重点。直接输出摘要，不要其他格式。</think>本集针对Spring JDBC中查询需反复手动创建BeanPropertyRowMapper的痛点，设计了一个通用BaseDao并封装泛型
2026-08-31 17:12:01
451
原创 ⚡ Spring JDBC 完整体系 · 第 5 讲 · Spring Boot Starter JDBC
Starter 做了什么本质依赖聚合一个依赖自动引入HikariCPspring-tx自动创建 DataSource自动创建 JdbcTemplate自动创建 TransactionManager自动创建 DataSourceInitializer外部化配置一行配置，自动读取并绑定Starter = 依赖聚合 + 条件化自动装配。
2026-08-30 09:33:04
546
原创 ⚡深度解构 MyBatis
MyBatis 解构：动态SQL的本质与简化 摘要 文章从一个50行的SQL字符串构建工具出发，揭示了MyBatis动态SQL的本质不过是一个复杂的SQL拼接机制。通过对比分析，展示了在简单工具与Spring JDBC组合下，可以更直观、更轻量地实现MyBatis 80%以上的核心功能。 关键发现： MyBatis的动态SQL实际上是被XML/注解包装的字符串拼接 简单SQL构建器+JDBC的组合代码量更少，可读性更好 复杂查询逻辑完全可以用Java代码直接补足，无需框架"退居二线" 链式调用是语法糖而非必
2026-08-23 16:58:05
537
原创 全面解构传统持久层框架，拥抱真正的 SQL-First
学 XML 标签、学 OGNL 表达式、学 resultMap 嵌套学 QueryWrapper 链式调用、学 Lambda 表达式构建条件学 JPQL、HQL、Criteria、QueryDSL……学 jOOQ 那套从数据库生成代码的流程最终，你发现所有这些学习曲线，都是为了绕开一个你本来就该会的东西：SQL。SimpleDAO 不让你绕弯子。它的价值从来不是“功能最多、最智能、最花哨”。“让你在写 SQL 的时候，少写那些重复的if和。仅此而已。
2026-08-22 00:53:45
519
原创 持久层框架的评价标准：只有一个
本文提出评价持久层框架的核心标准：SQL浓度。作者认为，持久层框架的好坏不在于功能多少或生态大小，而在于代码中SQL所占比例。真正的SQL浓度越高，框架越优秀；反之，配置、注解、Wrapper等"噪音"越多，框架越差。 文章对比了MyBatis、Hibernate等框架的SQL浓度，指出它们都存在大量非SQL代码（XML配置、Wrapper等）。作者提出自己的SimpleDAO方案，通过BaseDao和BaseCondition实现单表/联表统一处理，保持100%SQL浓度，无需额外配置。核心观点是：持久层
2026-08-19 22:00:12
444
原创 学习 MyBatis 到底有哪些“收益“？
文章摘要 本文通过两个真实场景对比了 Spring JDBC 和 MyBatis 在实际开发中的差异。第一个故事展示了一个简单分页工具的实现难度：Spring JDBC 组实习生一小时就能完成，而 MyBatis 组两年经验开发者也难以实现。第二个故事同样显示，在屏蔽判空 if 的需求上，Spring JDBC 实习生能轻松完成，而 MyBatis 专家却束手无策。作者指出，MyBatis 的扩展性被 XML 限制，其生态繁荣是通过"挖地道"实现的。最后通过1+1查询场景的代码对比，展示了 Spring J
2026-08-17 11:41:30
600
原创 我为什么从 MyBatis 切换到 Spring JDBC Ultra：一个真实项目的故事
/ 条件1：日期 + 班型（用于 CTE）@Override", inDate);// 条件2：签到明细（用于聚合子查询）@Override", inDate);// 条件3：学生 + 状态筛选（用于最终过滤）@Override我为什么从 MyBatis 切换到 Spring JDBC Ultra？答案不是“MyBatis 不行”，而是“MyBatis 太沉了”为了写动态 SQL，我得学 OGNL为了分页，我得引 PageHelper。
2026-08-16 14:26:39
431
原创 Java 持久层认知体系重构：Spring JDBC++ 实战推演
Java 持久层认知重构：Spring JDBC++ 设计与实践 摘要 本文系统性地解构了主流ORM框架的认知误区，提出基于Spring JDBC的轻量级持久层解决方案。通过对比分析MyBatis的十大常见误解，揭示XML配置与动态SQL的本质缺陷；展示Spring JDBC在生产环境中的实战优势，包括： 原生Java语法实现动态SQL（相比XML标签更类型安全） 9表联查场景代码量减少60-70% 统一的事务管理与监控能力 扩展基础组件实现单表CRUD自动化（约215行核心代码） 完整保留SQL控制权的同
2026-08-14 13:27:19
462
原创 ⚡事实与营销之间：MyBatis 与 Spring JDBC 的持久层技术复盘
摘要： MyBatis与Spring JDBC的技术对比揭示了前者在多个维度上的劣势。Spring JDBC在对象映射（一次映射）、动态SQL（Java原生支持）、执行路径透明度（白盒操作）、扩展性（AOP非侵入式）、调试体验（浅堆栈）及学习成本（1小时上手）上全面占优。MyBatis虽市场占有率高，但依赖XML配置（二次映射）、黑盒执行链路、复杂拦截器机制及额外学习负担（OGNL、缓存等），实际编码量未减少，反增维护复杂度。技术层面，Spring JDBC更高效透明，MyBatis的市场成功或源于营销而非
2026-08-13 09:25:00
533
原创 Spring JDBC 被低估了吗？—— 关于 MyBatis 与 Spring JDBC 复杂度的祛魅
本文对比分析了MyBatis与Spring JDBC的核心差异，指出主流观点存在认知偏差。通过信噪比分析，揭示MyBatis的XML配置实际带来70%以上无关噪音，而Spring JDBC的"冗长"仅是Java语法本身。深入剖析MyBatis设计缺陷：其复杂度源于解决自创问题（如OGNL、XML标签等），而非数据库访问本质；动态SQL只是将Java逻辑平移到XML，未提升抽象层级；黑盒设计导致扩展困难，需掌握复杂插件机制。相比之下，Spring JDBC保持透明性，直接使用Java控制逻辑，通过AOP即可简
2026-08-09 10:57:51
599
1
原创 SQL-First 范式：一种面向业务结果的持久层设计
SQL-First范式：重塑持久层设计的业务导向方法论 摘要： 本文提出SQL-First持久层设计范式，直击ORM与MyBatis的核心矛盾——3GL（Java等）与4GL（SQL）的天然语义鸿沟。基于集合论与图论的本质差异，论证了两种语言体系无法完美映射的数学根源。通过分析SQL子句的动态性梯度，构建三层架构：BaseCondition管理高动态WHERE条件、BaseSql作为纯执行通道、BaseDao实现单表自动化。该范式遵循"双不封装"原则（不篡改SQL语法、不屏蔽数据库能力），以simple-d
2026-08-08 15:49:45
693
原创 MyBatis 真相拆解：一份关于“默认选项“的祛魅报告
MyBatis 祛魅：一场关于默认选项的技术与社会学思辨 本文通过六部分剖析MyBatis流行背后的真相： 概念偷换：MyBatis并未真正"封装"SQL，仅完成代码载体从Java到XML的转移，反而增加了字符串处理复杂度 XML代价： 代码量膨胀2倍以上 维护时需跨文件同步修改 调试困难（无法断点/复杂异常栈） SQL表达能力弱化 优点祛魅： "生态成熟"实为功能缺失的补丁生态 "可控性"与JDBC无异 "DBA友好"在OGNL嵌套中失效 异常体系：30+框架特有异常掩盖真实数据库问题 流行动因： 历史真
2026-08-07 23:17:29
483
1
原创 AI 是非专业人士的玩具，是专业开发者的工程提效利器
真正的专业开发者使用 AI，核心不是 “让 AI 代替自己写代码”，而是在完整的工程约束下，让 AI 承接重复性、机械性、低思考成本的工作。对专业开发者而言，AI 是精准可控的 “提效利器”，在规范约束、边界清晰、合理分工的体系下，能极致压缩重复工作量，聚焦核心业务与架构决策。未来的软件开发核心竞争力，早已不是 “会不会写代码”，而是会不会定义边界、会不会拆分任务、会不会规范工具、会不会驾驭 AI。行业里大量的 AI 生成垃圾代码，本质不是 AI 的问题，是无范式、无约束、无分工的野蛮开发模式导致的。
2026-08-06 19:32:35
521
原创 ⚡ Spring JDBC 完整体系 · 第 8 讲 · 查询四象限完备
本文摘要介绍了Spring JDBC查询操作的"四象限完备"方法论，将SQL查询结果归纳为四种形态：单行单列（如聚合函数）、单行多列（主键查询）、多行单列（单字段列表）和多行多列（标准列表查询）。教程通过实际代码演示了如何使用JdbcTemplate处理这四种场景，包括queryForObject、BeanPropertyRowMapper、SingleColumnRowMapper等核心API的用法，并附有完整的项目结构和前置配置说明。文章属于系列教程的第8讲，后续将继续深入工具封装和框架扩展内容。
2026-08-05 20:30:55
368
原创 ⚡ Spring JDBC 完整体系 · 第 7 讲 · NamedParameterJdbcTemplate 命名参数模板
本文介绍了Spring JDBC中NamedParameterJdbcTemplate的使用方法，重点讲解了如何通过命名参数解决传统JdbcTemplate中占位符顺序记忆问题。主要内容包括： 命名参数优势：使用:name形式替代?占位符，摆脱参数顺序依赖 环境配置：无需额外依赖，Spring Boot已自动配置NamedParameterJdbcTemplate 核心用法：通过MapSqlParameterSource进行参数绑定，支持链式调用 底层原理：命名参数在运行时会转换为标准的PreparedSt
2026-08-04 11:01:08
500
原创 ⚡ Spring JDBC 完整体系 · 第 6 讲 · JdbcTemplate API 精讲（上）
本文是Spring JDBC教程第6讲，主要讲解JdbcTemplate的核心API使用。文章首先介绍了前置知识要求，包括Java基础、Spring Boot基本用法和基础SQL知识。随后展示了项目结构，包含Maven依赖配置、H2数据库配置、日志设置和建表脚本。重点讲解了JdbcTemplate的设计理念：不区分单表/联表，完全支持原生SQL执行，将SQL控制权交给开发者。通过User实体类示例，演示了BeanPropertyRowMapper如何自动完成数据库字段到Java属性的下划线转驼峰映射。最后给
2026-08-02 12:38:56
578
原创 ⚡ Spring JDBC 完整体系 · 第 5 讲 · Spring Boot Starter JDBC
本文介绍了Spring Boot Starter JDBC的使用，通过一个依赖替代手动配置，简化JDBC开发流程。主要内容包括： 依赖对比：spring-boot-starter-jdbc聚合了spring-jdbc、HikariCP和spring-tx 核心配置：只需配置数据源URL和SQL初始化脚本 代码演示：展示了实体类、DAO层实现和Spring Boot启动类 日志配置：开启SQL执行和参数绑定的详细日志 通过Starter机制，开发者无需手动注册DataSource、JdbcTemplate等B
2026-07-31 09:49:38
537
原创 150 行代码，吊打 MyBatis 全家桶
这篇文章提出了一种基于Spring JDBC的轻量级ORM方案（150行核心代码），宣称能全面超越MyBatis及其全家桶。核心观点分为两个层次： 150行代码实现MyBatis核心功能： 通过BaseCondition类实现动态SQL（50行） 通过BaseDao类实现物理分页（40行） 相比MyBatis减少XML配置，使用纯Java实现更透明可控 扩展为Spring JDBC Ultra框架： 单表CRUD零配置，支持逻辑删除等特性 原生SQL处理联表查询，统一API简化复杂查询 强调真实业务90%是
2026-07-28 17:41:29
423
原创 ⚡ Spring JDBC 完整体系 · 第 4 讲 · 连接池 + 事务管理器
本文摘要： Spring JDBC 第4讲重点讲解了连接池和事务管理器的生产级实现。相比第3讲的基础配置，本讲主要升级了3个关键点：1) 使用HikariCP高性能连接池替代DriverManagerDataSource；2) 通过@EnableTransactionManagement开启事务支持；3) 配置DataSourceTransactionManager作为事务管理器。文章通过UserDao的三种场景测试（正常提交、无事务异常、带事务异常）展示了事务管理的实际效果，并详细分析了每种场景下的日志输
2026-07-27 11:10:40
468
原创 ⚡ SQL-First 范式：持久层设计的终极解
做 Java 后端开发快二十年，持久层框架换了一茬又一茬。从裸写 JDBC，到 Hibernate 一统天下，再到 MyBatis 成为国内行业标配，还有 Spring JDBC 不温不火当了二十年的「背景板」。所有人都默认一个潜规则：持久层领域存在一个不可能三角——「单表对象化便捷」「100% SQL 能力可控」「扩展灵活低成本」，三者最多占两个，不可能全部兼得。我偏不信这个邪。花了三年时间打磨出（内核名 SimpleDAO），又花了一年时间沉淀出支撑它的底层理论——SQL-First 范式。
2026-07-23 21:43:01
717
原创 MyBatis 大清算：技术路径依赖下的集体认知失调
摘要：MyBatis技术清算——集体认知偏差下的范式困境 文章对Java生态中MyBatis的统治地位提出颠覆性质疑，指出其所有技术优势均为市场运营和路径依赖造就的认知假象。通过全球编程语言持久层范式对比，揭示MyBatis的XML模板模式是2000年代模板引擎狂热的历史残留，与现代"逻辑归宿主语言"的工程趋势背道而驰。作者以Spring JdbcTemplate为参照，逐条证伪MyBatis七大宣传优势： "SQL解耦"实为多文件强耦合 动态SQL是用残缺XML模拟Java基础逻辑 复杂映射在生产中普遍被
2026-07-22 14:36:37
638
原创 别再被「单表占 80%」骗了：持久层的主战场，从来都是联表
摘要 本文揭示了持久层开发中「80%业务是单表CRUD」这一说法的误导性，指出90%的开发时间和复杂度其实消耗在多表联查、动态筛选、聚合报表等复杂场景。通过对比MyBatis和Spring JDBC Ultra在两类典型场景的表现： 日常场景（12表联查+40动态条件）：展示Ultra保持SQL完整可读、声明式条件构建和数据权限注解的简洁性 报表场景（嵌套汇总+多条件组）：凸显Ultra的条件合并能力和原生SQL支持优势 文章强调优秀持久层框架应专注解决复杂查询痛点，而非仅优化简单CRUD，并指出智能COU
2026-07-21 14:35:20
402
原创 MyBatis 的技术“优越感”到底从何而来？一场关于工程化的反思
本文对MyBatis和Spring JDBC进行了深入对比，指出MyBatis存在过度设计、调试困难等问题，认为其"优越感"更多源于行业惯性而非技术优势。文章提出Spring JDBC Ultra（SimpleDAO）框架作为解决方案，它基于Spring JDBC进行深度封装，摒弃XML配置，将SQL逻辑回归Java代码，实现了强类型检查、透明调试和简易扩展，真正体现了"大道至简"的工程理念。该框架通过继承BaseDao即可获得完整CRUD能力，支持复杂查询和分页，大幅减少了样板代码，提高了开发效率。
2026-07-20 15:05:34
270
原创 你以为 MyBatis-Plus 单表是 yyds？这场心智负担的比拼，它从一开始就输了
👉延伸阅读：持久层的主战场，从来都是联表很多人觉得，不就是单表增删改查吗，能有多大差距？恰恰是这种「大家都能做」的基础场景，最能看出框架的设计功力。差的框架，把功能堆给你就完事了，你要记配置、踩坑、切换多套体系，心智负担全甩给开发者；好的框架，让你用的时候几乎感觉不到它的存在——不用记一堆规则，不用怕踩歧义的坑，不用在多套 API 之间反复横跳。Spring JDBC Ultra 就是后者。
2026-07-19 15:31:10
374
原创 一个查寝报表的重构：从 MyBatis XML 到 Spring JDBC Ultra
文章摘要： 本文将介绍一个职校宿舍管理系统月度查寝报表的重构过程，从MyBatis XML迁移到Spring JDBC Ultra。该报表需要处理三类复杂业务约束：动态变化的学员班级/床位关系（需使用快照表）、无班级学生用-1补全数据、查寝状态需组合映射。重构前的MyBatis实现采用"两次查询+内存组装"的方式，包含报表条件解析、快照表查询、状态组合计算等步骤。文章详细分析了数据流转全链路，并对比了两种技术方案的实现差异，重点阐述了如何通过数据建模简化复杂业务逻辑。
2026-07-18 13:03:51
1242
原创 ⚡ 持久层框架的不可能三角
摘要（149字）： 本文剖析了Java持久层框架二十年发展的"不可能三角"困境——单表便捷性、SQL自由度与扩展灵活性难以兼得。作者基于Spring JDBC打造Spring JDBC Ultra框架，通过五大创新设计实现突破：1）单表/联表统一API与条件类；2）多条件动态合并；3）自动判空消除90%样板代码；4）正交完备的16种查询API；5）声明式条件注册。最终在保持Spring JDBC白盒优势的同时，集成了Hibernate的单表便捷与MyBatis的SQL自由，代码量减少2/3，打破了持久层长期
2026-07-17 10:32:11
522
原创 ⚡ Spring JDBC 完整体系 · 第 3 讲 · Spring JDBC 最小案例
这篇文章摘要： 《Spring JDBC 完整体系 · 第3讲》介绍了Spring JDBC的最小实现案例，通过对比裸JDBC和Spring JDBC的差异，展示了Spring JDBC在简化数据库操作方面的优势。文章提供了完整的Maven依赖配置，核心代码演示了如何通过外部化配置、手动注册核心Bean（DataSource和JdbcTemplate）、自动初始化数据等步骤构建最小Spring JDBC应用。特别强调了BeanPropertyRowMapper在结果集映射中的便捷性，以及JdbcTempla
2026-07-16 11:07:43
305
原创 MyBatis：全球编程语言生态中的孤例，以及一个长达二十年的误会
这篇文章对比了Java生态中MyBatis与其他编程语言数据库访问方式的差异，指出MyBatis使用XML模板引擎拼接SQL的做法是全球编程语言生态中的孤例。作者通过分析前端模板引擎的兴衰历程，论证了"将逻辑塞进模板"是一种已被证明的弯路。文章指出，MyBatis的复杂设计本质上是为弥补"用弱逻辑语言(XML)模拟强逻辑语言(Java)"的缺陷，而其他语言普遍采用更直接的SQL字符串处理方式。最后，作者提出SimpleDAO方案，主张回归"SQL即字符串"的简单哲学，直接在代码中处理逻辑而非通过模板引擎。全
2026-07-15 10:18:08
587
原创 持久层框架终极对决：十维评分全景解析
本文对主流持久层框架进行全面评测，基于SimpleDAO v1.2.1源码和实际案例，从10个维度对比分析JPA/Hibernate、MyBatis/MP、Spring JDBC和SimpleDAO的性能表现。评测结果显示SimpleDAO在可用性、易用性、高效性等所有维度均获满分，总分100分，远超其他框架。文章通过8集实战教程详细展示SimpleDAO在单表CRUD、联表查询、多租户等复杂场景的应用优势，特别强调其SQL-First设计理念带来的开发效率和执行性能双重提升。评测指出传统ORM框架在复杂查
2026-07-14 11:16:46
583
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人