今天和面试官聊到 DAO 层时，面试官表示 JPA 很反人类

从来不用 JPA.不要让简单的事情变复杂.
有学习 JPA 的时间,能封装好几套 ORM 框架出来了.

jpa 这种在 数据写入的时候 可读性很高
数据查询的时候 一般普通查询 可读性也很高, 连表查询也很优雅
复杂查询的时候 我还是喜欢 sql

@jsou ...是吗？我觉得 JPA 还算简单的

那么 JPA 是什么

JPA 可以结合 sql 语句的 。使用 @Query 注解

使用 Mybatis 的路过。。。表示不知道 JPA 怎么玩

Jpa 多表操作就傻眼了

也没到反人类的地步，有时候挺好用的。

Mybatis 对于稍微会写 sql 的都没问题

多表查询时怎么办呢，复杂 SQL 语句怎么办呢，让 dba 优化 SQL 的时候怎么办呢。
每次用这类 orm 框架，碰到复杂的业务头就痛。
还是 mybatis 能直接看到 SQL 语句舒服。。

@eamon666 可以具像理解为 Hibernate 吧..因为 JPA 就是一个标准
@guoziyan 那个应该是 HQL 了吧？
@EXE 写 HQL 可破吧..
@zacard 是的。所以有点楞逼
@murmur 想起以前面试时当面给写复杂 SQL ，瞬间 SB 了

多表操作用 queryDsl ，单表操作一般就是 JPA 。比如： public List<User> findByNameLikeOrderByIdDESC(name, orderBy)。

@caixiexin 不是可以写 HQL 吗？ dba 优化倒的确是一个痛点

@Camile 复杂是指的过度设计.

从 jdbc->jdbctemplate->hibernation/mybatis 再到 jpa,真当开发人员的学习时间不要钱.

我觉得到 h/m 这一级的封装已经有点过了,再往深处走就有病了.

自己写个 orm 框架,几千行代码,多表\级联\校验\注解\日志\代码生成之类的都能实现了,还能按项目特性去保障性能.
就我自己做过的项目来说,会依据数据库可能出现的最坏场景,然后对我们自己写的 orm 框架进行一些微调,想怎么改就怎么改.用那些重量级框架,特殊需求满足不了\不小心出个 bug 能干翻 99%的开发人员\遇到性能问题都没处说理去.

@jsou 造轮子的人值得钦佩

@Camile 主要用 hql 的话，我觉得还不如直接上 mybatis 了，起码开发的时候代码中的 SQL 语句复制粘贴出来改下参数就能用了，放到 MySQL 中调试也方便。
jpa 或 hibernate 这类 orm 框架，团队中没有一个懂得多的大牛的话，感觉暗抗很多的。

@caixiexin 你说得也有一定的道理

@caixiexin 相比 JPA ，我觉得真正懂 SQL 的人更少。

@caixiexin 但事实上 xml 里面的语句写了一大堆套件判断

JPA 在最基本的 CRUD 场景下很好用，如果是跟 Spring boot 一起用，上手非常快。
前几天看到一个技术博客推荐的 mybatis 自动 sql 生成： https://piaoniu.io/pndaokai-yuan-liao/，提供的功能也就是 JPA 的子集。

纯用 jpa 是挺麻烦的，但是很 oo ，这就导致有些人懒得学懒得看，所以 jpa 不受待见……

@jsou 想法很天真。你觉得你自己开发的 orm 框架将来不需要维护吗？维护不需要成本吗？如何保证性能和正确性？我用过一些公司自己的设计的 orm 框架，比开源 orm 框架难用不说，还有各种资源泄露的严重系统级 bug 。

@jsou 故意找喷的？无脑装逼

@georgema1982 如何保证性能和正确性这个问题用在开源 orm 上也一样合适,回答不了,我只能说自己写的代码可掌控程度高一点.

@imcj orm 框架不像 spring,orm 只是面对数据持久化,没多少知识点,要装也不用这个装.已 block(v2 好像流行这个?)

这个问题就像月经帖一样 每个月都会被提那么几次。

用过，不太喜欢，可能功力不够，还是喜欢 Mybatis ，不过 JPA 规范那套接口设计的真他妈漂亮...

我觉得用 DSL 是个很好的平衡

JPA 这种标准只适合写 DEMO ，当然你也可以通过各种方式去实现多表复杂查询，但是为什么不用 Mybatis ？

233 这个时候可以推一下我们自己搞的一个基于 jpa 的封装了，大家有兴趣可以来试试嘛. 不过目前该框架只是对 query 进行封装，并不支持 join 查询。
https://github.com/elvis-liu/yaz

跟楼主想法一样， JPA 很好用开发效率很高，且无需关心底层数据库
但是遇到要优化 sql 的时候就.....我水平不够

在国内貌似很不受待见+1 ，不知道国外是怎么样的 ，以前看 youtube 上的 spring boot 讲座的时候，也是用的 jpa 呀
mybatis 可以用 mybatis-generator 生成 mapper ，缺点是生成的代码太多了，且数据库有变动的时候需要重新生成，自从用了这个后很少写 sql 语句了

其实 jpa 还是挺方便的，也可以自定义复杂 sql

慈禧第一次听说轮船不用牛拉的时候，认为那玩意真 TM low

@leopku 哈哈,给你一百个赞

sql 的全称是什么？请大声读出来！！！

JOOQ 是一个很好的平衡点



啪啪啪

@jsou 如果对“性能和正确性”的回答是“不知到”的话，这已经足够说明用自己所谓控制性高的自制框架的问题所在了

@georgema1982 性能和正确性这个问题,你去问任何一个框架,谁能三言两语的回答了.没有生产环境的检验,说明不了什么.
仅就 hibernate/mybatis 来说:
性能就从来不和 hibernate 搭边,对 hibernate 也不多说什么,我从参加工作开始,公司的所有项目选型中没人考虑过它;
mybatis 我也有在项目中用过,遇到最让我记忆深刻的问题就是一样的数据,一样的代码,在批量 insert 的时候当数据量到一定程度时,oracle10g 上报错,oracle11g 正常,手工执行 sql 没任何问题.一行一行调试源码找到问题所正,花掉的时间能打两场麻将了.

虽然造轮子一开始是浪费时间,但当遇到底层框架 bug 时,怎么可能有自己写的更得心应手.
当然我是指那些功能域单一的"小框架".像 spring 这种,没能力动它,只能乖乖的被它上.

不少[功能域单一的"小框架"]我所在的项目团队宁愿自己造轮子,也不愿再跳它们的坑,不仅仅是 orm.比如像:mina 遇到 cglib,atmosphere 遇到 weblogic,shiro 遇到静态化.没踩坑的时候总觉得它们千般好,踩过坑后,被它们浪费的时间,一个轮子造好了.

乐此不疲的造轮子的人都是从坑里爬出来的.

@jsou 小项目都自己造轮子，老板的开发成本 瞬间上升啊

@jsou 不过 Hibernate 确实太重了，学习起来成本太高了，只用 JPA 实现一些多表的功能又十分麻烦

@jsou Struts2 用的多么？

口味选择啦，话说我也比较倾向 MyBatis

JPA 几乎是我所有 Java EE 项目中作为 Persistence 的首选。

@danngo2455 JOOQ 对 JDBC 操作来讲不错，在一些场合我也会用到。另外就是 QueryDSL 的对纯 SQL / JPA 等的支持也相当不错。

MyBati 我永远都不会再选择。 Batis 在进入 Apache 前用过一次（当然 Batis 后来在 Apache 呆不住了），还不如 Spring Jdbc Template 简洁，为什么要用它？

开发时我们要考虑：

1. OOP 首先必须满足面向对象的要求，而不是要面向数据库。
2. 最近几年的项目，都是必须满足 Typesafe 查询，这些在 Hibernate ， JPA ， JOOQ ， Query DSL 都支持得很好。
3. 权衡数据库和 OOP 对象设计。

问过身边一些使用 MyBatis 的人，为什么喜欢它？理由很简单，只会一点 SQL ， MyBatis 拿就可以上手。一个共同点，没系统的学习过 Java 和 Java EE ，大多数连 Oracle 官方的 Java 和 Java EE 教程都没读过，更不说是读一本完整的书去系统学习知识，好不用说系统学习 JPA 了，平时写代码也就是只会一些 Copy 的工作。

@hantsy 2333 后面黑的太厉害了

@Camile 不是黑，最近帮朋友公司面试一些不少人，只会 Copy 代码的见得太多了。

以上回复也可以看出一些，如果你用 JPA 还在关心表，，，呵呵，基本上说明在滥用 JPA 了。

@EXE 用多表关联查询本来就会被骂

JPA 随着系统复杂度上升，可读性下降的很快（注解的通病），性能上也并不多亮眼。系统规模小且简单的话属于不错的选择。