混合持久化环境中Hibernate与JDBC共存的事务与性能实践

先从一个真实的问题说起。前阵子有个朋友问我，他们系统里有一张订单扩展表，字段有三十多个，其中一半是业务方临时加的冗余标记，今天加一列明天改一列，每次都要改Hibernate实体类、改映射关系、重新打包上线。他问我：这张表能不能不交给Hibernate，直接用SQL读写？我说当然可以，但你需要想清楚的不只是这张表怎么写，而是整个项目从那一刻起就进入了"混合持久化环境"。Hibernate继续管它擅长的领域模型和关联关系，JDBC Template乃至MyBatis去接那些字段不稳定的宽表、报表统计和批量任务，两边共存于同一个数据库、同一个事务边界内。

这不是"偷懒"，也不是技术洁癖的妥协。实际上，绝大多数跑了三五年以上的业务系统，早就处于某种混合状态，只是没人给这种状态起名字。很多人焦虑的是：Hibernate和原生SQL混用会不会冲突？事务会不会乱？缓存会不会失效？本文就围绕这一主题展开，把我在实际项目中踩过的坑、验证过可行的策略、以及最终沉淀下来的一套"混合持久化环境使用Hibernate"的实践方案拆开讲清楚。内容适合那些正在用Hibernate/JPA，又不得不面对SQL、多ORM、NoSQL共存的开发者，也适合准备接手老项目的同学。

1. 为什么好好的项目会走到"混合持久化"这一步

1.1 从一次"能不能别全用Hibernate"的争论说起

朋友问的那张订单扩展表，本质上暴露了Hibernate的一个特性：它让"数据模型"和"Java对象模型"强绑定。实体类的字段、类型、关联关系一旦确定，改起来就要经历"数据库DDL变更—实体类变更—映射关系核对—重新编译部署"这条完整链路。对稳定业务来说这是优势，因为类型安全、IDE支持好、无痕的延迟加载让开发效率很高；但对那种字段像流沙一样的表，优势就会反过来变成负担。

于是团队里很容易出现一种声音：这张表直接用JdbcTemplate写两个方法，插入和查询都走SQL，不香吗？确实香。但问题也随之而来：如果一条业务逻辑里既要用Hibernate更新订单主表，又要用JdbcTemplate更新扩展表，事务怎么保证？如果一个查询返回的DTO里既有Hibernate加载的实体属性，又有JdbcTemplate查出来的统计字段，会话和连接管理怎么做？这些问题不解决，混用就是埋雷，稍微一碰就炸。

1.2 生产环境里最常见的四类混合场景

• 第一类是历史系统接管，老库里有一堆设计得比较随意的表，主外键都没几个，强行用Hibernate映射成实体反而别扭，不如SQL直读。
• 第二类是复杂报表统计，多表JOIN、多层子查询、动态条件拼装，Hibernate的Criteria和HQL在这类场景下可读性差、优化空间小，SQL的可控性优势就体现出来了。
• 第三类是边缘写入场景，比如批量导入、定时跑批、一次性数据订正，这些操作关心吞吐量而不是领域模型，用JDBC Batch或者StatelessSession更舒服。
• 第四类是多技术栈团队协作，部分服务用MyBatis，部分服务用JPA，两边共享同一套数据库Schema，在代码层面不得不交叉调用。

1.3 混合持久化不是偷懒，是架构对现实的妥协

很多架构师一听到混用就皱眉，觉得这是技术栈不统一、规范混乱的表现。但我观察到的真实情况是：一个运行了多年的系统，如果说"我们只用一种持久化方式"，那多半是嘴上的说法，而不是代码里的事实。Hibernate处理领域模型很强势，但在复杂查询、动态列、大规模批量更新上，它需要SQL来兜底。反过来，纯JDBC/MyBatis的团队在维护一对多、多对多的对象嵌套关系时，又需要Hibernate这样的ORM来节省重复劳动。

所以混合持久化不是要不要的问题，而是怎么面对的问题。用得好，它是一套"各取所长"的组合拳；用不好，才是事务错乱、会话泄漏的灾难现场。关键就在于边界、基础设施和事务纪律。

2. 边界怎么画：哪些实体该进Hibernate，哪些该走原生访问

2.1 一个最实用的切割维度：按数据域划分

网络上关于"什么时候用ORM、什么时候用SQL"的讨论很多，有的按操作类型分，有的按性能要求分。我在实践后觉得最可执行的规则是：按数据域划分，而不是按操作划分。

什么意思呢？同一张表，要么完全交给Hibernate管理，要么完全交给SQL访问层管理，不要两边同时操作。比如订单主表、订单明细表、客户表、商品表这些承载核心业务关系的数据，归Hibernate管，因为对象之间的导航很频繁；而订单扩展属性表、操作日志表、报表聚合表、临时中间表，归SQL访问层管，因为它们的形态不稳定、访问模式简单、几乎没有对象导航需求。

如果按操作类型分，比如"写走Hibernate、读走SQL"，很容易出现一个问题：Hibernate的一级缓存和二级缓存里存着旧状态的实体，而SQL读出来的是最新数据，两条路径对同一份数据出现不同的"视图"，排查起来非常痛苦。

2.2 一张表只允许一个所有者

我给自己定过一条纪律：任何一张业务表，在应用代码里必须只有一个持久化所有者。 要么你是Hibernate实体，要么你是JdbcTemplate/MyBatis的查询对象，不能两边都建一套映射。这条规则看起来简单，执行起来却经常被打破。常见的情况是：某团队把Customer表配成了Hibernate实体，后来另一个同事图省事，直接写了一条JdbcTemplate的update语句去改Customer表某几个字段。结果就是Hibernate的二级缓存里还是旧值，界面上看到的却是新值，数据明明已经改成功，但查询结果就是不对。

为什么强调"所有者"？因为持久化不只是增删改查，它还包括状态管理、缓存管理、并发控制。Hibernate拥有这张表时，它帮你管缓存、管脏检查、管乐观锁；你绕过它直接改库，它对你的越权行为毫无感知。反过来，如果表的所有者是SQL访问层，那Hibernate也不要去碰它，更不要试图把它Load成实体再save，因为中间隔着一层不同的状态管理语义。

2.3 那些"看起来能映射、其实不该映射"的伪实体

我见过不少团队把报表宽表做成Hibernate实体，理由是"既然有主键，映射起来也不难"。但从实践看，有几类表非常不适合纳入Hibernate实体管理：

• 字段经常动态增减的业务扩展表，每次加列都要改实体的滋味一点都不好受；SQL查询可以靠Map接收动态列，灵活得多。
• 宽表+大量聚合计算的结果集，比如订单统计表、日活汇总表，这类表天然是给查询优化器用的，挂到Hibernate上只会引入不必要的脏检查。
• 无主键或逻辑主键不稳定的流水表、日志表，Hibernate的Session缓存机制在无唯一标识时容易产生异常语义，还不如一条SQL插入一条SQL查询。

把这些表定义为"SQL访问层数据对象"，用DTO接收结果，反而能让代码结构和表结构一样清晰。

3. 基础设施埋线：SessionFactory与数据源如何协同

3.1 数据源必须是同一个，这是基础中的基础

在混合持久化环境里，第一件要确认的事是：Hibernate和SQL访问层使用的是同一个DataSource。如果Hibernate配了一个连接池，JdbcTemplate又配了另一个连接池，两个池子连的是同一个库，那么跨持久化层的事务协调就会变成一场灾难——你根本没法保证这两个连接上的操作在同一个物理事务里。

我见过最典型的低级错误：老项目里Hibernate用C3P0连接池，后来引入JdbcTemplate时图省事，直接new了一个DriverManagerDataSource。表面上功能没问题，但一旦某个业务流程在Hibernate里插入了数据，还没提交，又用JdbcTemplate去查询，结果查不到刚插入的数据，因为两个连接有的是隔离事务。这就是典型的混合持久化环境下的"幻读"事故。

统一数据源之后，所有后续的路都顺了。Hibernate从DataSource拿连接，JdbcTemplate也从DataSource拿连接，连接归属同一个事务管理器管理，事务边界就有了一致的前提。

3.2 一个可复用的SessionFactory配置参考

下面是一份我在Spring Boot项目中使用过的配置，混合了Hibernate 5.x和Spring JDBC，两个访问层共享同一个HikariCP数据源：

java复制@Configuration
public class PersistenceConfig {

    @Bean
    public DataSource dataSource() {
        HikariDataSource ds = new HikariDataSource();
        ds.setJdbcUrl(env.getProperty("db.url"));
        ds.setUsername(env.getProperty("db.username"));
        ds.setPassword(env.getProperty("db.password"));
        ds.setMaximumPoolSize(50);
        ds.setMinimumIdle(5);
        ds.setConnectionTimeout(30000);
        return ds;
    }

    @Bean
    public LocalSessionFactoryBean sessionFactory(DataSource dataSource) {
        LocalSessionFactoryBean sf = new LocalSessionFactoryBean();
        sf.setDataSource(dataSource);
        sf.setPackagesToScan("com.example.domain");
        Properties props = new Properties();
        props.put("hibernate.dialect", "org.hibernate.dialect.MySQL8Dialect");
        props.put("hibernate.show_sql", "false");
        props.put("hibernate.format_sql", "true");
        props.put("hibernate.jdbc.batch_size", "50");
        props.put("hibernate.jdbc.time_zone", "Asia/Shanghai");
        props.put("hibernate.connection.release_mode", "after_transaction");
        sf.setHibernateProperties(props);
        return sf;
    }

    @Bean
    public JdbcTemplate jdbcTemplate(DataSource dataSource) {
        return new JdbcTemplate(dataSource);
    }
}

这套配置的关键点有三个：

1. 同一个DataSource注入到SessionFactory和JdbcTemplate，保证所有数据库操作走同一个池子。
2. hibernate.jdbc.time_zone显式指定时区，避免数据库、JVM、应用服务器三方时区不一致导致的日期错乱，这个细节后面专门讲。
3. hibernate.connection.release_mode设为after_transaction，让Hibernate在事务结束后尽快释放连接，减少和JdbcTemplate抢连接的概率。

3.3 多个SessionFactory的事务协调思路

有些项目不止一个SessionFactory，比如一个连主库、一个连历史库，或者一个管业务域、一个管物流域。这种情况下，Spring里会出现多个事务管理器，默认的@Transactional不知道该用哪一个，程序启动时就会报"多个PlatformTransactionManager"的启动失败。

我在解决这类问题时，习惯先问一句："新的业务用例里，是否真的需要跨两个SessionFactory做强一致的写操作？"如果只是读多个库，那不需要揉在同一个事务里，分别用各自的Repository查询再组装即可。如果确实有跨库写并且需要强一致，那就要引入JTA/XA，比如Atomikos，但XA的性能代价和故障恢复复杂度很高，多数业务系统其实可以用"本地消息表+最终一致"来替代。如果你的场景只是两个SessionFactory各自管自己的业务域，有个别跨域写操作，我建议用ChainedTransactionManager合并事务管理器，代码简单，但它不是真正的分布式事务，遇到一个Manager提交成功、另一个提交失败时只能靠补偿逻辑兜底。

3.4 数据源密码这种基础问题也要同步管起来

很多人觉得"密码"这种词太基础，不值得写。但在混合持久化环境里，一个项目可以因为不同的访问层使用了不同的配置方式，导致同样的数据库密码被硬编码在三四份配置文件里。Hibernate的hibernate.cfg.xml里一份，Spring的application.properties里一份，某个老工具类里又写死一份。密码散落是安全隐患，更麻烦的是改密码时漏改一处，线上立刻故障。

我现在的习惯是：所有数据源密码统一走配置中心或环境变量，应用代码里不出现明文。如果项目还没接配置中心，也可以用Jasypt对配置文件里的密码做加密占位，像这样：

properties复制spring.datasource.password=ENC(加密后的密文)

数据源是混合持久化环境的第一道关口。密码统一管理，暴露面就少了一分。

4. 事务和会话编排：混合环境最容易翻车的重灾区

4.1 共享同一个Connection，是混用不混乱的底层原理

我在前面强调数据源必须统一，这里再从更底层讲清楚为什么。Hibernate的Session在需要访问数据库时会从DataSource获取一个Connection；Spring的JdbcTemplate在执行SQL时也会从同一个DataSource获取Connection。如果两边各自获取各自的连接，那就是两个独立事务，互相不可见。要让它们在同一个事务里，核心在于Spring的DataSourceUtils和TransactionSynchronizationManager这套机制。

当你在Spring环境中使用@Transactional声明事务时，事务管理器会先把Connection绑定到当前线程上。Hibernate的SessionFactory和JdbcTemplate都遵循同一个Spring事务抽象，所以它们拿到的Connection实际上是同一个。也就是说，在同一个事务方法里，你用Hibernate写了一条insert，再用JdbcTemplate在同一事务里执行update，两条SQL作用于同一个数据库连接，要么一起提交，要么一起回滚。

这正是混合持久化环境最关键的"地基"。只要地基对了，上面怎么配合都不乱；地基错了，什么最佳实践都白搭。

4.2 Spring托管事务下的推荐写法

在Spring Boot项目中，最常见的正确写法是这样的：

java复制@Transactional
public void createOrder(Order order, List<OrderItem> items) {
    // 领域核心数据走Hibernate
    orderRepository.save(order);

    // 扩展统计数据走JdbcTemplate
    jdbcTemplate.update(
        "INSERT INTO order_stat (order_id, total_amount, created_at) VALUES (?, ?, ?)",
        order.getId(), order.getAmount(), order.getCreatedAt()
    );
}

这段代码看起来平淡无奇，但在混合持久化环境里，它的成立依赖三个前提：数据源统一、事务管理器统一、实体Repository和JdbcTemplate在同一个事务内注册。只要这三个前提在，Hibernate写入和JdbcTemplate写入就是同一个事务里的两个步骤，要么都成功，要么都回滚。

这里有个容易被忽略的细节：order.getId()能否在save之后立刻取到，取决于主键生成策略。如果采用IDENTITY自增列，Hibernate会立刻执行insert来获取主键，所以save之后ID一定可用；如果采用SEQUENCE或TABLE生成器，Hibernate会延迟到flush时才真正插入。所以在混合操作时，如果你的后续SQL依赖Hibernate实体的主键，最好在save之后显式调用一次session.flush()，先把insert语句发给数据库，再让JdbcTemplate访问数据。不然就可能出现JdbcTemplate查不到刚插入数据的情况。

4.3 手动事务边界下Hibernate的配合姿势

不是所有项目都用了Spring框架，很多人维护的老代码里还是手工session.beginTransaction()。这种环境下混合使用Hibernate和JdbcTemplate，要格外小心flush时机：

java复制Session session = null;
Transaction tx = null;
try {
    session = sessionFactory.openSession();
    tx = session.beginTransaction();

    Order order = new Order();
    order.setAmount(new BigDecimal("199.00"));
    session.save(order);
    session.flush(); // 关键：先把Hibernate挂起的SQL发出去

    // 这时JdbcTemplate才能在同事务连接上读到刚插入的数据
    jdbcTemplate.update(
        "UPDATE order_stat SET stat_status = 1 WHERE order_id = ?",
        order.getId()
    );

    tx.commit();
} catch (Exception e) {
    if (tx != null) {
        tx.rollback();
    }
    throw e;
} finally {
    if (session != null) {
        session.close();
    }
}

这段代码里的session.flush()不是可选项。Hibernate的save本身可能只是把对象标记为持久化，并没有立刻生成SQL。如果不flush，JdbcTemplate在同一事务里查到的还是旧数据。你可能觉得"事务没提交，本来也查不到"，但注意：同一个Connection上未提交的数据，对自己是可见的。所以关键不是"查不到"，而是Hibernate的SQL还没发出去，JdbcTemplate当然无从可查。

4.4 会话生命周期管理：别让Session替你背锅

混合持久化环境里另一个高频翻车点是Session生命周期。

在Spring环境下，很多人使用sessionFactory.getCurrentSession()，这个API要求配置好hibernate.current_session_context_class=thread或者依赖Spring的Session绑定。它的特点是：当前线程没有Session时创建，事务提交后自动关闭，听起来很省心。但如果你在同一个线程里先跑了一次Quartz定时任务（没有事务），又跑了一次业务查询，Session的绑定关系可能混乱。

而在非Spring环境或传统Servlet环境里，更常见的做法是sessionFactory.openSession()，拿到一个独立的Session，用完必须手动close。问题是，很多从Struts2+Spring+Hibernate时代过来的老代码，Session.open之后忘记在finally里关闭，连接池就这么被一点点耗尽。你还以为是C3P0配置问题，实际是Session泄漏。

我的一点建议是：如果代码里大量使用openSession()，花一点时间统一收敛到getCurrentSession()，或者收敛到一个封装了try-with-resources的DAO基类里。让每个Session都在明确的边界内创建和销毁，这是混合持久化环境里唯一的硬规矩。

4.5 日期夏令时问题：一个隐藏的时区坑

“hibernate日期夏令时报错”这个热搜词，我在实际项目里也遇到过。印象最深的一次是：数据库里存的是一个夏令时切换日的时间，应用读出来之后莫名其妙少了一小时，或者反过来多了一小时。追查下来发现，三层时区配置打架了。

Hibernate 5.2之后提供了hibernate.jdbc.time_zone，可以显式指定读写数据库时使用的时区。JDBC驱动在连接串里也有一个时区参数，比如MySQL的connectionTimeZone。数据库服务器还可能有自己的time_zone变量。如果应用层是Asia/Shanghai，数据库层是UTC，连接串又没指定，那么Hibernate写入Timestamp时按照连接默认时区转了一次，读出来又按JVM默认时区转了一次，这一来一回可能就差出几小时。

我的建议是：在配置里显式把Hibernate的时区、JDBC连接时区、数据库会话时区统一到同一个值。业务系统里大部分日期其实用LocalDateTime就够，但如果你确实需要存Timestamp，那就要留意时区转换。混合持久化环境下更烦人的是：Hibernate实体用的是java.util.Date，JdbcTemplate查出来的却是java.sql.Timestamp，两种类型在比较时很容易触发时区二次转换。统一时区之后，这类问题能瞬间少掉一半。

5. 从"能用"到"好用"：性能监控与问题定位

5.1 打开Hibernate统计，但别只盯着它

当系统进入混合持久化状态，Hibernate统计信息依然有参考价值，但不再完整反映数据库访问全景。你可以在hibernate配置里打开统计开关：

properties复制hibernate.generate_statistics=true

启动后通过日志或JMX能看到Session打开次数、一级缓存命中率、二级缓存命中率、SQL执行次数和平均时间。这些数据对定位Hibernate侧的N+1问题、缓存滥用问题很有帮助。

但真实场景里，混合持久化系统的性能瓶颈往往出在Hibernate看不见的地方。比如一个页面渲染需要查客户信息，Hibernate负责查实体，然后服务层为了补齐某个扩展字段，又调了一次JdbcTemplate。单独看Hibernate统计，每条SQL都很快；整体看接口耗时，请求数翻倍了。这时候你要做的不是优化Hibernate的抓取策略，而是把视角拉高，看整条调用链上的数据库交互次数。

5.2 N+1在混合环境里的全新变种

经典N+1问题是指查询出N条主记录后，每条主记录又各触发一次子查询，总共产生1+N次SQL。混合持久化环境下，N+1会换一副面具：Hibernate查出N个实体，服务层为了实现某个汇总字段，循环调用了N次JdbcTemplate查询。这种问题在代码里很难一眼发现，因为每次JdbcTemplate调用的SQL看起来很干净，没有离谱的JOIN，但数量是N次。

我遇到过一次很典型的案例：订单列表接口，Hibernate分页查出20条订单，然后循环里用JdbcTemplate去查每笔订单下的最新操作日志，最终结果就是一次分页查询+20次日志查询。接口看起来不慢，但数据库负载就是居高不下。解决办法有两种：要么用一条带窗口函数的SQL直接查出20条日志，要么用WHERE order_id IN (:ids)一次查出来再在内存里组装。核心思路是：混合持久化给了你两条路，但不要用两条路去表达同一个循环。

5.3 慢SQL到底由谁负责定位

混合持久化环境下，DBA或中间件监控会给出慢SQL列表，但一个棘手的问题是：这条SQL到底是Hibernate生成的，还是JdbcTemplate里手写的？如果是Hibernate生成的，日志里可能是一行带?占位符的HQL/JPQL，需要把它映射回实体类和查询方法；如果是JdbcTemplate手写的，那就直接看SQL本身。

我在项目中习惯给两类访问打上不同的日志标记。JdbcTemplate对应的方法统一走一个带marker的Logger，Hibernate的SQL则通过hibernate.show_sql或hibernate.session.events.log查看。这样定位慢SQL时，先按Logger查源头，再按SQL特征确认归属，效率会高很多。

另外一个实用技巧：给每一条报表类SQL加注释，比如/* orderStatDailyReport */ SELECT ...。MySQL、PostgreSQL的慢日志都会保留注释，下次收到告警时，一眼就能认出这条SQL是谁家的，而不需要翻代码。

5.4 缓存失效策略的跨层思考

Hibernate有二级缓存，JdbcTemplate/MyBatis通常没有默认缓存，但业务代码常常在Redis里再套一层缓存。混合持久化环境下，跨层缓存失效是我踩过最深的坑之一。

简单说：Hibernate更新了一张实体表，触发了二级缓存的失效，但某个统计接口的Redis缓存并不会自动失效，因为那个统计接口压根不走Hibernate。结果就是Hibernate这边改完立刻能看到新数据，Redis里的统计结果却还是半旧的，用户看到的数据一会儿新一会儿旧。

最直接的应对方案是：Hibernate侧的表发生变更后，通过Spring事件发布一个CacheEvictEvent，在事件监听器里删除关联的Redis缓存key。如果不想引入事件机制，给报表缓存加一个很短的TTL也能缓解，比如30秒。在混合持久化环境里，"缓存的所有者"也要和"表的所有者"一样清晰，谁改了数据，谁负责通知失效，绝不能指望对方自动感知。

6. 老项目改造实战：struts2 + hibernate + c3p0如何演进

6.1 先别动手，把改造目标想清楚

有不少老项目的技术栈是Struts2 + Hibernate + C3P0，很多人就是跟着韩顺平老师的Hibernate视频教程（31讲）入的门，那套学习路径帮人理解了ORM的基本原理，但直接照搬到今天的工程实践里，会遇上不少新问题。比如Struts2时代的请求线程模型、Hibernate 3/4的API习惯、C3P0的连接池参数，和现在微服务化、接口化、多数据访问层共存的场景已经有很大距离。

如果你要改造一个这样的老系统，我建议第一步不是改技术栈，而是先把"如今有哪些表其实没在走Hibernate"摸清楚。很多老系统里，报表统计、批量处理早就用原生JDBC写了，只是没人整理。先画出全量SQL访问清单，按我前面说的"表所有者"规则归类，再决定哪些继续留给Hibernate、哪些迁移到统一的SQL访问层。

6.2 C3P0连接池参数在混合环境下的调优

老项目里C3P0是标配，但在混合持久化环境下，C3P0需要重点关注几个参数：

混合持久化环境里最典型的问题是：Hibernate的Session持有连接时间过长，JdbcTemplate拿不到连接，表现为"并发一上来，连接池就耗尽"。排查时先看是在哪个访问层卡住的。如果是Hibernate，检查Session释放逻辑，看是否有openSession忘关；如果是JdbcTemplate，重点看是否有循环里频繁获取数据库连接的操作。

6.3 渐进式混合化的三步走

• 第一步，先统一数据源。把项目里所有散落的DataSource实例收拢成一个，Hibernate和JdbcTemplate共用，这一步做完，事务混乱的隐患就消除了大半。
• 第二步，把报表和批量处理里的原生JDBC代码收拢到统一的Repository层，用JdbcTemplate重写，让所有非Hibernate访问有统一的入口和日志标记。
• 第三步，再考虑把部分字段频繁变化的表从Hibernate实体改为SQL访问。注意，这一步要仔细看代码里有没有人对这张表执行过HQL、Criteria查询，有没有和其他实体做过关联。只要有过，迁移成本就高一些，要慎重。

7. 混合环境下的三个"纪律"与我的真实体会

如果要用几句话总结我踩了这么多坑之后的经验，大概就是三条纪律。

第一，表的所有者必须唯一。Hibernate管哪些表、SQL访问层管哪些表，要在架构文档里写清楚，代码评审时重点检查有没有"跨界访问"。第二，事务边界必须清晰。无论用@Transactional还是手动事务，都要保证Hibernate和JdbcTemplate在同一个事务里工作，数据源必须是同一个。第三，缓存的责任人必须明确。谁改了数据，谁负责通知缓存失效，不要把这个问题留给运气。

最后再分享一个我自己的操作习惯。在引入JdbcTemplate之前，我会先看一眼目标表是否被Hibernate的二级缓存管理。如果是，我会尽量通过Hibernate的事件监听来做缓存同步；如果不是，我才会放心使用SQL访问层。判断这门"手艺"是否熟练的标准很简单：当你需要查一个合并在同一张表里的字段时，能用Hibernate就用Hibernate，能用一条SQL就用一条SQL，但永远不要让两条路在同一行数据上打架。

混合持久化并不可怕，真正可怕的是没有边界的混用。把边界划清楚，基础设施搭对，事务和缓存管理到位，Hibernate在混合环境里依然能当它的"领域模型管家"，SQL往该去的地方去，各得其所，系统也就稳定了。