- 博客(424)
- 资源 (6)
- 收藏
- 关注
RSS订阅原创 第十二课实战版：登录系统工程实战：JWT + Redis + 拦截器完整设计
本文介绍了基于JWT和Redis的工程级登录系统实现方案。核心架构采用JWT负责身份验证、Redis管理登录状态、拦截器处理请求身份恢复的三层设计。系统实现了完整的登录流程控制，包括：1）登录时签发JWT并写入Redis；2）请求拦截器校验token有效性；3）支持单点登录和强制下线；4）细粒度401错误码区分；5）全链路日志追踪。关键技术点包括JWT最小化payload设计、Redis登录态管理、拦截器鉴权链路实现等。该方案确保了登录系统的可控性和安全性，解决了传统方案中无法强制下线、权限变更延迟等问题，
2026-01-31 08:30:00
249
原创 Android Native 层是如何运行 ART 与 Native Libraries 的？
本文从工程实现视角解析Android系统的Native层架构。Native层并非单一模块，而是由ART运行时、NativeLibraries(.so)和NativeService(C++进程)共同构成。ART通过zygote进程启动并fork到各应用进程，与NativeLibraries是协作关系而非驱动关系。NativeLibraries通过三种方式加载：进程预加载、JNI显式加载和Native进程直接加载。Native层通过JNI、Binder IPC和系统调用三种机制向Framework提供能力。理解
2026-01-31 05:30:00
710
原创 第十二课：登录系统完整拆解——Session、JWT 与后端身份模型
本文揭示了后端登录系统的复杂性，指出登录本质是身份状态管理而非单一接口。文章对比了Session和JWT两种身份验证机制：Session是服务端状态型系统，JWT则是自包含令牌。实际工程中往往采用混合方案（JWT+Redis）来解决纯JWT无法即时失效的问题。成熟的登录系统需要包含凭证生成、登录态管理、风控等多个模块，并与网关、异常处理等工程能力协同工作。文章强调登录系统是基础设施而非功能接口，理解身份模型是后端开发的重要能力。
2026-01-31 03:15:00
673
原创 fork 是什么？——为什么它是 Android 运行模型的真正核心
本文揭示了Android系统高效运行的核心机制——Linux的fork系统调用。fork通过"写时复制"技术实现低成本进程复制，解决了ART运行时初始化耗时的难题。Android启动时，zygote进程作为ART模板初始化完成，后续通过fork快速创建system_server和所有App进程，共享已初始化的运行时环境。这种设计避免了重复初始化ART带来的性能损耗，使系统启动更快、内存占用更少、运行更稳定。文章通过对比传统进程创建方式，阐明了fork在移动设备资源限制下的不可替代性，并形
2026-01-30 22:48:27
434
原创 Android 系统中 ART 是如何运行的？——从 zygote 到每个 App 的真实模型
Android系统并非只有一个ART实例在运行。系统启动时，zygote作为首个ART进程常驻内存，预先完成ART初始化。随后通过fork机制创建system_server（系统服务）和各个App进程，每个进程都拥有独立的ARTRuntime实例。这种设计实现了快速启动、内存优化（COW机制）和进程隔离，确保系统稳定性。简言之，zygote是ART的"模板工厂"，而system_server和App都是其派生的独立ART实例，随进程生命周期创建和销毁。
2026-01-30 22:34:48
692
原创 Binder 是如何贯穿 ART / Native / Kernel 的？
本文深入解析了Android中的Binder机制，指出其并非单一组件，而是贯穿用户态与内核态的IPC体系。Binder分为三层：内核层的Binder驱动负责基础IPC；Native层的libbinder提供面向对象封装；ART层的JavaBinder则是Native的Java适配。真正的IPC发生在Native与内核层，ART仅作为桥梁。这种分层设计既保证了内核简洁性，又实现了语言适配，是Android系统服务的基础。核心在于：Binder的核心是Linux驱动，ART只是其使用者之一。
2026-01-30 22:19:26
850
原创 第十一课实战版：接口质量工程 —— 参数校验、幂等、防重、版本控制
《接口系统工程防御能力建设》是一套系统化解决方案，聚焦接口系统的工程防御能力。课程核心包含三层能力：稳定性底座（第9课）、Controller规范（第10课）和本课的现实世界防御能力。重点培养工程师设计抗重复请求、并发、重试、误用等现实场景的接口系统能力，要求实现统一参数校验、幂等设计、防重防刷、版本控制等工程组件。通过四级幂等方案（唯一约束、Token机制、状态机、去重表）和分层防御模型，构建从网关到业务的完整防护体系。课程最终目标是让开发者形成接口质量的条件反射，实现从功能开发到工程设计的思维跃迁，使接
2026-01-30 07:00:00
334
原创 第十一课：接口质量工程 —— 参数校验、幂等、防重、版本控制
《接口工程：对抗混乱现实的四大防线》摘要 本文系统阐述了构建高质量接口系统的核心工程思维。接口质量不仅要求功能正确，更需要建立四大工程防线：1）参数校验作为第一道门，需建立完整的接口契约；2）幂等设计是应对重复请求的核心能力；3）防重防刷机制抵御恶意与误操作；4）版本控制保障系统演进能力。文章强调从"功能正确"转向"工程正确"的思维转变，通过参数校验、幂等处理、防刷机制和版本控制等工程手段，使接口系统能够应对真实世界的重复请求、网络抖动、恶意攻击和版本演进等挑战，最终
2026-01-30 05:00:00
582
原创 为什么有的 Android 架构图是 4 层，有的却是 5 层？
摘要：Android架构图存在4层和5层两种表述，本质是不同时代背景下的视角差异。早期4层图（应用层、框架层、库与运行时、Linux内核）反映Dalvik时代的实现状态，当时HAL尚未标准化；现代5层结构（新增HAL层）源于Treble计划对硬件抽象层的强制解耦，能更好解释系统升级、厂商适配等工程问题。两种分层不存在对错，4层是历史实现视角，5层是当前系统设计视角，HAL的独立成层标志着Android架构的重要演进。学习Framework等深层原理时应采用5层认知模型。
2026-01-29 23:19:28
607
原创 从 0 理解 C++ 操作符重载：operator 是什么？为什么能 cout ＜＜ 对象
C++操作符重载本质上是为运算符定义函数行为，让自定义类型支持标准运算。通过operator关键字可以将运算符转换为函数名，如a+b等价于operator+(a,b)。cout<<obj是重载左移运算符的结果，其本质是调用operator<<(cout,obj)函数，通过返回ostream&实现链式调用。操作符重载并非创造新语法，而是为已有运算符补充针对特定类型的实现规则，使自定义类型能像内置类型一样使用标准运算符。理解操作符重载的关键在于将运算符自动转换为对应的函数调用形式
2026-01-29 19:30:39
573
原创 JWT 这么流行，为什么还要 Session？——强制下线到底怎么做？企业真实登录系统揭秘（工程视角）
本文解析了企业级登录系统的架构设计，指出JWT与Redis Session的结合是现代主流方案。核心观点包括：1）JWT负责跨系统身份传递（自描述凭证），Redis实现分布式Session控制登录态；2）强制下线通过更新Redis中的有效会话标识实现，而非使JWT失效；3）该架构兼具无状态身份传递和有状态登录控制能力，支持跨系统协作与安全策略。本质是"JWT解决身份携带，Session控制身份认可"的职责分离模式。
2026-01-29 13:39:23
465
原创 第十课实战版：Controller 层的正确打开方式 —— 接口不是业务层
本文系统阐述了后端开发中Controller层的核心定位与最佳实践。Controller作为协议适配层，需严格遵循"接收请求→校验→转换→调用→返回"的五步流程，禁止处理业务逻辑。文章详细规范了工程目录结构、参数校验机制、DTO转换规则，强调通过Assembler隔离接口与系统模型。重点指出Controller应专注协议处理，业务异常统一交由全局异常处理器，保持代码纯净度。该设计模式能有效构建清晰的系统边界，提升接口质量与系统稳定性，是开发者从功能实现迈向系统架构的重要标志。
2026-01-29 05:00:00
1082
原创 第十课：Controller 层的正确打开方式 —— 接口不是业务层
本文阐述了Controller层在后端架构中的核心定位与规范。文章指出，Controller层本质是"接口适配层"而非业务层，只应负责5件事：接收输入、参数校验、模型转换、调用服务和统一返回。同时明确禁止在Controller中处理业务逻辑、控制事务或操作数据库等行为。通过标准工程结构和接口流程示例，强调Controller应保持"干净"才能确保系统稳定，这是区分功能开发与系统工程的重要标志。掌握这些规范能帮助开发者从高级工程师视角进行接口系统设计。
2026-01-29 03:00:00
690
原创 第九课：异常与日志体系——后端稳定性的第一道防线
文章摘要：异常与日志是后端系统的核心防线，它们确保了系统的可生存性。异常不是简单的报错，而是对业务失败的工程建模，包括业务异常、系统异常和致命异常三类。设计异常体系需遵循统一出口、语义化和分离原则。日志则用于记录系统行为，应包含上下文信息并分层处理。成熟的异常与日志体系能快速定位问题、触发告警并支持监控修复，这比CRUD更重要，体现了系统工程能力。
2026-01-29 02:00:00
512
原创 第九课实战版：异常与日志体系 —— 后端稳定性的第一道防线
本文摘要：第9课聚焦构建后端工程的稳定性基础设施层(Infrastructure)，相当于Android中的base模块。课程目标包括：建立统一异常处理体系(业务异常/系统异常)、规范错误码、实现全局返回体Result、集成requestId全链路追踪、制定日志分层规范。通过创建common基础模块，形成包含统一异常处理、错误码体系、日志规范等核心组件的工程闭环。该基础设施层不处理具体业务，但为后续Controller规范、接口质量等提供系统性支撑，是构建稳定后端系统的关键地基。
2026-01-28 12:59:02
33
原创 第八课：Service 层到底写什么？——从 CRUD 到业务编排
本文深入探讨了后端开发中Service层的核心定位与实践误区。文章指出，许多项目将Service层简化为DAO的中转站，导致"贫血Service"和伪分层架构，这是后端工程上限低的关键原因。实际上，Service层应作为业务用例层，负责业务流程编排、业务规则承载、事务边界控制及多模块协作，而非简单的增删改查。合格Service层应体现业务语义，包含多个步骤和业务判断，像流程图而非SQL集合。文章强调，Service层是系统复杂度的主要承载者，决定了后端工程师的技术段位，是从"接
2026-01-28 08:00:00
857
原创 Service 与 Biz 的真正边界：业务用例 vs 业务能力
文章指出后端开发中常见的误区：Service层沦为"业务垃圾场"，承担过多职责。作者提出应将Service定位为"业务用例层"，专注流程编排；而引入Biz层作为"业务能力层"，负责规则校验和业务计算。两者的关系是Service组合Biz完成业务用例，Biz为Service提供可复用的业务能力。当Service出现大量重复逻辑或复杂判断时，就需要引入Biz层来管理业务复杂度。Biz层不是简单的工具类，而是具有明确业务语义的能力模块。这种分层架构能有效
2026-01-28 07:15:00
556
原创 从 CRUD 到模块化：企业真实项目结构演进蓝图——后端的“领域拆分”，其实就是服务端的组件化
本文揭示了企业后端系统演进的真实路径：从CRUD项目起步，逐步发展为业务系统、拆解业务内核，最终实现领域模块化。核心观点指出，优秀架构不是预先设计，而是业务需求倒逼的演进结果。关键在于将业务能力封装为可独立迁移和复用的模块，使系统增长方式从"堆代码"转变为"加模块"。文章提出了四个演进阶段及判断标准，强调模块化的核心价值在于解决企业级复杂度治理问题，其本质是服务端组件化架构。最终合格的架构应具备模块边界清晰、可独立迁移等特性。
2026-01-28 05:00:00
977
原创 最小后端服务的数据库与事务设计（工程级实战）
本文以"最小可运行后端服务"为例，深入剖析了工程级后端系统的数据库与事务设计要点。文章指出系统稳定性的关键在于：1）合理的数据建模，包括核心表、扩展表和业务实体结构；2）严格的表设计原则，如业务主键、唯一性约束和关系索引；3）正确的事务边界划分，强调事务应控制业务一致性而非简单防写入。作者提出后端服务必须处理三类事务场景（原子性、并发性和异常回滚），并给出数据库设计与事务复杂度的内在关系：表结构决定事务难度。最终结论指出，良好的表设计降低复杂度，合理的事务设计保障稳定性，这是工程型后端开
2026-01-27 08:00:00
1011
原创 最小后端服务的 SQL 工程视角：从写对到写好
本文探讨了后端开发中SQL从"能用"到"工程可控"的进阶要点。文章指出工程级SQL应关注数据访问路径、索引使用、并发行为和系统资源消耗。重点介绍了最小后端服务必备的四类SQL：主键查询、业务键查询、分页查询和更新操作，强调Explain分析的重要性。提出了五个升级点：字段选择优化、索引命中率、规模预判、业务与统计分离、业务模型对齐。最后指出SQL能力直接关联业务模型、系统性能和成本控制，是后端工程师的核心工程能力。
2026-01-27 06:00:00
513
原创 一个最小后端服务的工程结构拆解——从 Controller 到数据库的全链路视角
本文通过构建"最小可运行后端服务"，剖析了标准后端请求的完整处理链路。文章将后端系统划分为接口适配层、业务流程编排层、业务核心层和基础设施实现层四个层级，并以"创建用户+初始化账户"为例，详细展示了请求从Controller到数据库的全流程。重点强调各层的职责边界：Controller负责协议适配，Application层编排流程，Domain层专注业务规则，Repository定义数据能力接口，Infrastructure实现数据持久化。这种分层架构能有效隔离变化，
2026-01-27 05:00:00
537
原创 为什么 Service 层不能只写 CRUD——后端业务边界的真正意义
摘要：Service层不应仅是CRUD包装，其核心价值在于表达业务用例和系统流程。健康Service层应具备四大职责：业务流程编排、事务边界控制、业务建模和系统协作入口。CRUD型Service会导致业务逻辑分散、事务混乱和架构难以演进。正确做法是将CRUD下沉至Repository，让Service专注于业务逻辑编排（如registerUser、createOrder等），而业务规则应放在Domain层。Service层是决定"系统能干什么"的关键架构层，而非简单的数据存取层。当Ser
2026-01-26 15:25:30
710
原创 后端各层是否都要有数据 Bean？——一次把 DTO / Command / Entity / PO 的边界讲清楚
摘要：后端架构设计中，数据对象分层是核心原则。系统应划分为接口层（DTO/VO）、应用层（Command/Query）、领域层（Entity）和基础设施层（PO），各层维护专属数据模型。关键是通过转换器（Assembler/Mapper）实现跨层数据流转，避免对象污染。这种分层设计能将业务变化、接口变化和存储变化隔离在特定层级，保障系统长期可维护性。典型架构问题包括Controller直接使用Entity或Domain对象包含持久化注解。合理的对象分层是后端系统从"写接口"到"
2026-01-26 14:47:07
356
原创 后端到底是什么架构？——从 MVC、三层、DDD 到洋葱/六边形的一次工程级对照
本文从工程视角解析后端架构的本质，指出后端核心是解决业务复杂度和系统演进问题，而非UI架构。通过剖析主流架构模式（MVC、三层、DDD等），揭示其共通的四层结构：Interface层负责协议适配，Application层进行流程编排，Domain层承载业务模型，Infrastructure层实现技术细节。强调架构成功关键在于维护清晰的层级边界（如Domain层不依赖技术实现）和正确的依赖方向，而非架构名称的选择。文章提供可直接落地的工程结构模板，并指出Domain层的质量决定系统上限，建议开发者聚焦业务内核
2026-01-26 14:04:46
558
原创 Spring Boot Controller 从 0 入门：注册接口 + 项目结构 + 最小 Maven 配置一次讲清
本文介绍了如何编写结构清晰、职责明确的后端Controller。文章首先明确了Controller的定位是接口层/HTTP适配层，只负责参数接收、校验、调用Service和返回响应，不处理业务逻辑。然后给出了合理的项目分层结构（接口层、应用层、领域层、基础设施层）和最小Maven配置（仅需spring-boot-starter-web和validation）。最后以用户注册接口为例，展示了从DTO参数校验、Service调用到统一响应返回的完整实现流程，强调了Controller应该保持简洁，仅作为HTTP
2026-01-26 07:00:00
623
原创 Android 系统层到底是什么？AOSP / Framework / AMS·WMS·PMS 一次讲清
这篇文章总结了作者对Android系统层的认知转变：从应用开发转向操作系统级工程视角。核心内容包括：1）AOSP是Android系统的开源实现工程，厂商基于此定制ROM；2）Framework作为系统核心层，提供四大组件、权限等基础能力；3）三大核心服务AMS（进程调度）、PMS（权限管理）、WMS（显示管理）的职责与协作；4）系统层工程师主要从事平台能力建设、系统优化、硬件适配等工作。作者强调，系统层开发本质是操作系统级工程，需要建立平台思维，理解系统边界和能力分层。
2026-01-26 05:00:00
1111
原创 从 Android 到后端：Controller 与 RESTful 的一次彻底祛魅
文章摘要：本文系统梳理了后端开发中的核心概念认知升级过程。从Controller本质（HTTP适配层）到系统分层架构（Controller/Service/Domain/Repository），再到DTO/VO等数据传输对象的工程实践。重点剖析了RESTful的本质是资源状态表述（URL+HTTP方法+状态码+返回体），而非简单注解使用。通过对比Android开发中的Retrofit等网络请求框架，揭示了前后端序列化/反序列化的统一原理。最终指出技术认知的关键在于"拆解能力"——将复杂概
2026-01-25 06:30:00
1388
原创 锁到底在锁什么？——从 Java 锁到数据库锁，从代码到系统一致性
本文系统阐述了并发控制中的锁机制。核心观点：锁的本质是控制共享资源的修改权，解决多执行单元并发修改时的数据一致性问题。从单机到分布式，锁分为语言层、数据库层和系统层三个层级，其中数据库锁是企业系统的核心战场。文章详细对比了行锁/表锁、共享锁/排他锁、悲观锁/乐观锁等机制，特别强调MVCC保证读并发、锁保证写安全、事务保证原子性的分工协作。通过库存案例揭示锁防超卖的本质价值，同时指出锁会带来性能损耗。最终强调锁是保障系统有序运行的底层秩序，而非简单的并发补丁。
2026-01-25 06:15:00
623
原创 第七课：事务到底是什么在控制？——Spring 事务机制彻底讲透
事务本质是控制业务过程的安全边界，确保在并发和异常情况下系统可靠运行。ACID四大特性分别解决不同问题：原子性保证多步操作全成或全败，一致性维护业务规则不被破坏，隔离性控制并发事务的可见性，持久性通过日志确保数据不丢失。Spring事务通过统一模型、自动边界控制和AOP机制简化事务管理，提供传播行为、隔离级别等五个维度的控制能力。需注意事务并非万能，防并发竞争需结合锁/版本机制。事务的核心是维护系统状态机，保障业务世界的稳定性而非单纯防错。
2026-01-24 08:00:00
1316
原创 从 4 类模型到 MapStruct / Assembler：我是如何理解“对象转换”这件事的
后端开发中常见的代码混乱问题根源在于数据模型转换未收口。真实业务场景会自然产生四类数据对象：DTO（接口协议）、Command（业务参数）、Entity（数据库存储）和VO（展示数据）。这些对象间的频繁转换会导致Service层被set/get淹没、模型混用、转换逻辑分散等问题。解决方案是将转换逻辑抽离为独立架构层，使用MapStruct处理简单映射，手写Assembler处理复杂聚合。通过建立明确的转换边界，使业务层保持纯粹，系统获得更好的可维护性和演进能力。这标志着从"写接口"到&q
2026-01-24 06:00:00
672
原创 第四课：持久化层设计（JPA / MyBatis / 事务 / Repository）
本文系统讲解了后端持久化层的核心概念与实践要点。首先指出持久化层是后端系统的地基，决定了性能、稳定性和架构质量。文章对比了JPA和MyBatis两大主流技术路线，阐明Entity/DO/PO作为数据载体的作用，强调Repository/Mapper作为数据访问层的边界。重点讲解了事务管理的关键性，推荐了企业级持久化层结构，并指出事务应放在Service层实现。全文旨在帮助开发者掌握工程级的数据库操作技能，避免成为简单的CRUD开发者。
2026-01-23 08:15:00
443
原创 第三课：后端工程结构怎么设计？——从“能跑”到“能活三年”
《后端工程结构决定系统寿命》摘要：优秀的后端工程结构是系统长期健康运行的关键。文章指出，大多数项目失败源于结构混乱导致的模块耦合、改动恐惧等问题。作者提出"五层架构"解决方案：接口适配层、业务编排层、业务核心层、技术实现层和通用规范层，强调每层应严格遵循单一职责原则。特别区分了DTO、Entity和Domain三种模型，防止数据与业务逻辑混杂。文章还详细阐述了HTTP、RPC、MQ等不同入口的处理规范，主张通过清晰分层实现业务与技术解耦，使系统具备应对业务增长和技术演进的弹性。
2026-01-23 08:00:00
833
原创 DTO / VO / Entity 到底有什么区别？——后端分层中最容易混、但最关键的模型边界
本文阐述了后端开发中DTO/VO/Entity三种模型的核心区别与应用规范。Entity面向数据库存储，DTO负责接口传输协议，VO处理业务展示逻辑。三者分离能有效隔离变化：数据库修改不影响接口，接口调整不影响业务展示。文章通过Android架构类比（Entity≈RoomEntity，DTO≈API模型，VO≈UI模型），强调模型分层的重要性，并给出落地建议：数据库层用Entity，接口层用DTO，返回前端统一VO转换。这种分层架构能避免后期项目出现数据库与接口强耦合、修改牵一发而动全身的问题。
2026-01-23 07:00:00
1009
原创 一篇搞懂 SQL JOIN：从直觉到工程实战
JOIN本质是关系型数据库的核心操作，决定了数据如何基于关联条件组合成结果集。INNER JOIN只保留有关联的数据，LEFT JOIN确保左表数据完整（业务中最常用），RIGHT JOIN工程中基本不用。理解JOIN能解决ORM的N+1查询问题，避免循环查表。性能关键在索引和关联设计，而非JOIN本身。从数据建模角度看，JOIN是关系模型到业务模型的映射手段，决定了结果集的筛选规则（保留/丢弃数据）。掌握JOIN思维能打通数据库设计、查询优化和ORM使用。
2026-01-23 06:30:00
708
原创 第六课 · 6.4 企业真实选型：MyBatis / JPA / 混合架构
本文探讨了企业项目中持久化技术选型的演变过程。随着系统规模扩大，技术选型从单纯比较MyBatis与JPA优劣，转变为根据系统特性进行合理分工。文章指出，选型取决于系统性质、发展阶段、团队能力和风险模型，本质是组织能力的映射。JPA适合业务驱动型系统前中期，MyBatis则适合数据工程型系统。中大型系统通常会混合使用两者：JPA负责业务模型和写操作，MyBatis处理复杂查询和读操作。成熟团队更关注责任划分而非技术本身，最终目标是建立"写有秩序，读有效率"的持久化体系。
2026-01-23 06:30:00
1025
原创 第六课 · 6.3 ORM 为什么一定会有坑？——从 N+1 到事务错觉
摘要：本文剖析了ORM框架常见问题的本质原因，指出这些"坑"并非设计缺陷，而是对象世界与数据库世界交互时必然产生的系统副作用。文章通过N+1查询、懒加载异常、事务错觉等典型场景，揭示其根源在于：对象图与表结构冲突、持久化上下文边界、缓冲层机制等系统特性。同时指出MyBatis同样面临结构映射带来的新问题。最后强调，成熟的工程思维不是规避ORM，而是理解其运行时机制，通过明确边界、控制加载策略等方式系统性地管理复杂度。核心观点：ORM问题源于系统抽象的本质特性，只有深入理解其运行机制才能有
2026-01-22 17:36:28
393
原创 第六课 · 6.2 JPA 的核心到底是什么？——Persistence Context 与对象状态机
JPA的核心在于对象管理而非简单查询，其本质是维护对象在内存与数据库间的一致性。关键要理解持久化上下文（PersistenceContext）和实体生命周期（EntityLifecycle）：持久化上下文作为"数据库版对象堆"负责对象唯一性、状态管理和变更跟踪；实体状态机则定义了对象在Transient、Managed、Detached、Removed四种状态间的流转。JPA通过脏检查和工作单元模式实现自动更新，这种封装带来高效开发的同时也导致行为不够直观。正确学习路径应从理解这些核心机
2026-01-22 15:54:54
425
原创 第六课 · 6.1 从 JDBC 到 MyBatis：SQL 工程化是如何发生的？
MyBatis本质上是解决JDBC工程化问题的SQL映射框架。它通过结构化SQL管理、标准化参数绑定、自动化结果映射和动态SQL语言化，将原始JDBC升级为可治理的工程能力。不同于ORM，MyBatis专注于SQL执行与对象转换，保留了数据库设计的自主权，特别适合需要精细控制SQL性能的场景。其核心创新在于Mapper接口抽象，使数据访问层具备接口化、可测试性和可治理性。MyBatis在复杂查询、核心数据通道等关键场景中发挥着重要作用，是数据库工程化的重要工具。
2026-01-22 13:18:25
431
原创 第六课：ORM 是什么？——从 JDBC 到 MyBatis / JPA 的一次认知升级
本文揭示了ORM框架的本质不是简单的"数据库查询工具"，而是完整的对象持久化体系。文章对比了MyBatis和JPA两条技术路线：MyBatis定位为SQL工程化框架，强调数据库性能控制，适合核心交易系统；JPA则是对象持久化运行时，通过状态机管理对象生命周期，适合业务建模系统。作者指出二者本质区别在于系统哲学不同，并强调ORM应被视为基础设施层。最后提出数据访问层的完整架构视图，从业务对象到存储引擎的完整层次结构。文章旨在帮助开发者建立对数据持久化体系的整体认知框架。
2026-01-22 12:53:22
548
8方向控制圆盘-android
2025-10-30
Android Dsbridge （前端Vue3.0打包）
2025-10-30
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人