新手刚学 mybatis ，发现每次使用都要配一堆层，所以心中有个疑惑，为啥这么麻烦还是有一堆人用？是因为在实践中可以解决啥问题吗

门槛低：只要你 sql 写得好，mybatis 用起来就不会有太大问题；但是你 sql 写得好 jpa 也不一定玩得转对数据库设计要求低：想怎么设计就怎么设计，只要你的 sql 写得出来，而且工作量不会增加太多； jpa 就得按照规范设计，不按照规范就会陡增工作量

我也不懂为什么这玩意这么多人用，国外的 JPA 和 Hibernate 感觉用起来舒服多了，虽然细节坑不少但多查查文档翻一下社区也能弄出七七八八来，而且兼容性更好。

那为什么不用 mybatis-plus 呢

为了避免配置繁杂问题，用起来更方便，所以有了 mybatis-plus 。

你可以把 service 层省掉，就留一个 controller

现在的低代码框架可以直接生成 CURD 包括多表带条件代码，生成不了的肯定比这个复杂，一般都是报表或者树啊嵌套查询这类的，都是得手写 sql 的，手写 sql 还是 mybatis 用着舒服

业务简单直接 controller 调用 mapper 就行，有各种代码生成器，使用中坑少学起来快，很快就能上手干活

直接用 mybatis-plus 舒服很多；再用 Hibernate 完成同样的功能（特别是关联表）就会更明白他们的差异，Hibernate 并不是所有人都可以玩得溜；

JPA+QueryDSL

JPA 需要符合规范的设计，但是业务中你很难从头设计库表，很多情况下是接烂摊子

你把其他 orm 框架都用一遍，再选觉得顺手的就行，每个人体质都不一样，不一定用的多的就适合你。当然公司里团队协作需要技术栈统一除外

直接用 mybatis-plus 会舒服很多，单纯用 mybatis 就要写很多繁杂的东西

你说的分层是软件架构设计，跟用什么工具没关系，跟什么语言也没关系。层是分离职责和管理依赖关系的方式。 每个层都有特定的责任。 较高层可使用较低层中的服务，反之则不行。传统的三层应用程序有表示层、中间层和数据库层。 中间层是可选的。 更复杂的应用程序可以多于三层。

一堆层是指啥啊 这个和 mybatis 关系也不大把

service 层是有必要的, 去掉后就变成业务代码在 controller 了, 代码贼脏, service 层直接写实现类不要弄个接口就好了.

简单项目我都用 jdbctemplate

hibernate 的问题在于 sql 一复杂就嗝屁了。

我觉得配置也没有多复杂，特别是配合 Springboot 配置也没有那么复杂，最主要是可以自定义 sql

单论 mybatis 我觉得不好用 mybatis-plus 也是

service 不是必要的，看业务复杂度。1.去掉 service 接口，直接用 service 类 2.大多数接口在 controller 写了，因为逻辑并不复杂，只有遇到逻辑很多的才在 service 写。所以 service 的代码其实很少也很好看。

新手认为所有逻辑都写在 sql 语句里,然后调 sql 就行了是吧?,没 serviceimpl 做逻辑调用回滚啥的,光跑 sql,头轻脚重,该多看看开源项目

感觉不如 nextjs react component 里调 sql

我也不懂，明明 List

那就是我说的, controller 一堆业务逻辑, service 层是变好看了, 但 controller 层变得丑陋不堪, 每次看到这种代码都让我严重怀疑开发人员的水平.

黑盒子不利于后续接手维护，虽然烂摊子真的很烂

干脆直接给个接口，前端直接传 SQL 查数据库

数据库建模，上手简单，会写 sql 就能用，没有太多魔法额，为啥不用 jdbcTemplate 呢，，，

估计很多人没玩过 ddd ，，，加油吧

另外，很多人估计没写过复杂的业务。

楼主是不是从别的语言转过来的?还是 java 是你的第一门语言?

如果说手写 SQL 舒服的话， 哪个不支持 native Query裸写 SQL 根本就不能算 mybatis 的优势mybatis 用的人多完全就是因为阿里系在用这个，然后带起来的目前我这里的感受是：数据访问层一般情况下只负责最基本的 CRUD ， 业务行为放在领域中，这样这个项目才有可能控制得住一旦让写了两三年的小兄弟放飞自我，什么牛鬼蛇神都写得出来

感觉这玩意儿根本不是 ORM

MyBatis 和 MyBatis-Plus 的缺点借用别人的观点：dao 层和 sevice 层交叉混用。比如一个用户查询，用 UserMpper 查询也行，用 UserService 查询也行，想用哪个用哪个。----对比 JPA----MyBatis 允许开发人员自定义 SQL 语句，适应特定的业务需求。JPA 更倾向于使用命名查询和基于方法名称的查询，可能在某些情况下不如自定义 SQL 灵活。JPA 不鼓励写手动写 SQL 语句，鼓励要用 JPQL 。使用原生 SQL 时可能会失去一些 JPA 提供的跨数据库的抽象和便捷性。对于开发时表结构改来改去的时候，手写 SQL 方便。当业务逻辑复杂，使用 JPA 生成的 SQL 也复杂到让人看不懂的时候，手写 SQL 直观灵活方便调试。

web 应用分多少层取决于你应用体量，如果你业务共通逻辑很少，完全可以 controller 直接操作 mapper ，那帮喜欢 Java 胡乱分层，Service 里只有一句话的，基本你让他回答为什么分层，他都只会回答一句为了规范，实际屁都不是。事实上做 Service 层的目的其实仅仅是为了代码复用抽共通逻辑或者为了好写 aspect ，分层的时候一定要想清楚这一点，不要为了分层而分层。

＃23 你这是动态语言写多了吧。实际业务要是参数或者返回值搞这种 map jsonobject 之类，估计直接开骂了

是的，对于多数 crud 直上直下 service mapper 功能已经重复了，service 本来应该组织业务逻辑和事务等反而没有体现出来，其实对于只有 crud 直上直下这种其实 mapper 都可以不需要存在，只有 model(entity) 即可，尽信模式不如没有模式，简单的 crud 无需这么多层

我始终认为 orm 的玩法才是正道，其他都是玩具

灵活是以可读性和调来调去查看 map 里面是啥为代价，当这段代码只面向前端还好，当多人配合时 map 里有啥，idea 的提示就全废了，bean 是一种 struct ,提供了一定程度的约束

因为灵活，可以创建 sql 片段，动态 sql 可以应付最复杂的分支

一堆人用，不一定是好用，而往往是没得选。如果你不用 mybatis ，那么剩下的只有两条路：Hibernate ，但是门槛高，不适合国情；啥也不用直接用 JDBC + 手写 SQL ，项目规模稍微超过 「 Hello World 」就更麻烦了。（其实还有 JPA 的其他实现，但是比 Hibernate 门槛更高还不一定有它好用）上面说得是体系区分，实际应用中，不管是 mybatis ，还是 Hibernate ，直接用都还是更麻烦，还会有上层封装来做可用性提升。像 mybatis 就有 Mybatis Plus （这俩其实是不同开发团队搞的，不应该混为一谈），Hibernate 则是 Spring Data Jpa 。关于 Hibernate/Jpa 的门槛，需要说一句，它并不只是它们本身的学习门槛，而是设计理念和开发过程门槛：你不一定非要用 DDD ，但一定是拿「实体」或「模型」来作为需求或业务的主要描述语言。

这不是 mybatis 的锅，而是 java 过度设计的锅

JPA 党都是推崇，什么不用写 sql 啦，入手快啦，实在不行我还能写 JPSQL 之类的但当我真的打算用 JPA 去做企业应用的时候，就难受的一批你们真的明白一个查询几百行 sql 的感觉吗是，是可以把逻辑抽取到代码里面执行我何必啊？大部分都是中间表明细表，我还得单独为这十多个表建 entity ？我只需要为结果负责就可以了，中间的规范并不重要性能？ Oracle 数据库，硬件继续堆，企业应用又不需要互联网这么高的并发，硬件够我照样能跑mybatis 还可以做很多 DDL 的骚操作，JPA 用起来就显得麻烦我自己的项目当然可以按照 JPA 的规范，从头到尾设计的漂漂亮亮，按照开发规范设计但是按照这样设计之后，遇到复杂的业务逻辑，累的还不是我自己？sql 一把梭哈，做完项目拿完奖金就改跳槽下家了还隔这代码规范呢，代码我都想给他混淆再留下来

以為 JPA / Hibernate 不能裸寫 SQL ，就和用了 jQuery 以為 jQuery 不能混寫 JavaScript 一樣奇葩.就像 jQuery 會鼓勵你用 jQuery, 因為一旦你裸寫混寫 JS (比如混寫原生 Array.prototype.indexOf ，而不用 jQuery.inArray )，就會失去跨瀏覽器的抽象.所以 JPA 一樣鼓勵你 JPL, 少用 nativeQuery.我參與過一個項目用 JPA 相容了三種資料庫，Oracle , SQL Server, MySQL. (因為要部署在客戶的環境，客戶會考慮 DB 價錢.)(裸寫 SQL 就像停留在 ES3 時代，沒跨入 jQuery 時代)

JPA 也用过，MyBatis 也用过，目前的业务只有 mybatis 最顺手。之前做 CMS 的时候，jpa 顺手。用哪个取决于项目。

像一些后台管理类的代码，很多是简单的 curd ，不超过 5-10 行的，直接在 controller 写问题不大的，要 controller 与 service 里面跳来跳去更烦。

hibernate 搞 dto 之类的很大一部分原因是 entity 是由 hibernate 管理，hibernate 会自动把内存中的 entity 的状态和数据库同步，所以要隔离前端传来的数据和数据库数据mybatis 搞这么多层是？

什么一堆层？基础的 mvc 的话 Dao service Controller 还有 对应的 Model （ entity ） entity 就是接收数据库数据映射的。至于其他 VO BO PO DTO 都是出于业务需要增加的

1 、思想：mybatis 面向过程开发JPA （ Hibernate ）面向对象开发2 、侧重点：mybatis 采用 XML 管理 SQL 比较直观，查询多的场景比较自由灵活、缺点存一些符号冲突（<>），管理思想还是面向过程，需要通过 Plus 加强对象管理JPA 将数据库完全映射为对象需要有业务的整体设计能力，JPA 优势是简单的 CURD 根本不写 SQL ，JPA 缺点就是需要了解数据状态同步管理，复杂的业务尤其需要了解实体各个阶段状态，以及复杂的连表查询需要调用 JPA 的原生查询接口或者 DSL3 、抽象能力mybatis 使用原生的 SQL 方言，迁移能力比较差JPA 使用 HQL 屏蔽了底层方言差异抽象的比较彻底，迁移能力比较强

你需要被其他 orm 框架教育一下.

你们真有用过 jpa 写统计报表吗?

＃39 面向前端也不行，都用 ts 了，然后接口一堆 any ，想想就头大

受教了，老哥，感谢。

看了一圈，问下有人用 Spring Data R2DBC 吗？ spring.io/projects/spring-data-r2dbc

jpa 坑太多了，直接过滤

jpa + jdbcTemplate

一堆层和 mybatis 没啥关系，纯粹是 java 的一般抽象结构…而且这个结构其实还蛮合理的，除了 service 必须写个接口算是糟粕。

我也觉得 mybatis 得手写代码，简单的也得手写，虽然 mybatisplus 可以不用手写简单的 sql ，但是限制很大，比如不能连表。而且我也不懂为什么数据传来传去都得用实体类 哪怕传一个 id 都得用个实体类，在写接口的时候，会接收一些其他的参数，不可能只会出现数据库字段，于是又得扩展实体类。所以我下定决心开发出了一套库，以上的都改了，我大概描述下：

我用 mybatis ，根本不用写任何的 xml 。直接注解写 sql 就行。

直接将 sql 相关的语法转换成 java 的那一套，比如 Select(表名).field(字段).where("id",1).and().where("age",">",3).order("time")。大概这样，伪代码展示下，联表的话，join("left","user","order.user_id=user_id")，这样可以避免输入错误。然后也返回 list 和 map ，没有对象那一套，service 传的话，也是需要什么传什么，如果非得实体类 比如一下子传很多，也可以传 然后查询的时候拆了，这块我也没有怎么思考，所以很粗略。

手残分出好几个来，以上就是抛砖引玉了， github.com/dawnflyc/JqlApi分为几个库，一个 api 库定义了语法之类的，然后如果用 mybatis 的话 需要一个 mybati 实现库，如果用 jdbc 的话，需要一个 jdbc 实现库，需要什么导入什么，只是封装而已，并没有写核心的东西，以为我水平也达不到。

＃58 小哥，我想请教你一下。我前段时间跟着一个项目，基本没写什么联表。比如说一个返回结果他要包括两张表的信息，但是在 sql 里讲师并没有去写连表查询，而是用一个包含了那两张表字段的类，作为 VO 封装类返回，然后在 Service 层里，通过一些方法去把那两个实体类对象的字段 set 到 VO 封装类里，最终返回。我在想这样是不是也能去写 sql 的连表查询吧，因为在 Service 层里，针对这个查询功能写的逻辑比较多，有一点点繁琐。一般现实开发环境中，连表查询写的多？还是我描述的这种方法居多？或者根据业务需求决定的？

为什么不直接用 jdbcTemplate 呢

java 这么强悍的面向对象语言，居然还要手搓 sql ，搞个舒服的 orm 不可以吗？ 还是 laravel 的 orm 嗨皮

jpa 默认你的数据库表设计符合 ddd ，然而现实是你维护的系统数据库表都是前面的人随意设计的

我上面写的那个，就是感觉竟然没有一个好用的 orm ，所以自己照模照样搞了一个

那如果又有一个接口 不需要那么多字段 因为会泄露信息吗 那又得新建一个 vo ，太麻烦了。一般联表挺多的呀。我之前那个项目 有小区、楼栋、单元、楼层、户，然后就是一长链，然后就需要挨个查，一长链联表，很折磨。我也是一个新手呀

＃67 确实，那个项目因为有些查询不需要那么完整的字段，然后又担心泄露，确实建了几个 VO ，搞得还挺麻烦的。

事实上除了国内也没人用这玩意

技术上没有什么东西能同时满足解决复杂的问题并保持简洁，如果有，那只能说明问题不够复杂。就像 JPA/Hibernate 或者 Spring Framework ，了解的多才有信心写得少。

jooq 其实也不错 逃

我也是这样

发现 Java 和数据库相关的怎么那么多都是有收费选项的，flyway 和 liquibase 也是这样的，redisson 也是

楼上都说为啥明明一个 List<Map<K,V>>就能解决的问题非要建一堆 vo 、bo ？说明接手的二开和维护的项目少，看看一堆不按开发规范的 SB 写的代码，返回直接用 map.put 搞，简单的业务逻辑还好，复杂的业务逻辑得从这个函数甚至其他类、函数开始看，一点点的捋才知道这个 map 有哪些字段；调试的时候挂了还好，生产一挂，日志没有，纯靠瞎猜有了 vo 、bo 、dto 之后，debug 只需要看下对应的 pojo 就知道这个函数返回啥了，就算注释少，只要按着开发规范基本上都能看到个七七八八，心智负担大大降低。以前我也觉着写这 b 玩意麻烦，但是现在这么多 json 转 bean 工具，最多多几十秒的工作量，维护起来真的是香的不行

赞同，写 Map/JSON/BeanUtils.copy/动不动就自己造轮子，感觉大部分都是被外包带坏了，这种项目如果后面加功能/维护，那会就想日个🐎了

就一层啊 哪有一堆层

mybatis 怎么不叫 orm ？

不建 vo ，光用 map ，你怎么知道 map 里有哪些数据？今天你能记得，一年后呢？更不用说其他引用的人，一个 map 传数据，他怎么知道你 map 里有什么？

orm 的全称是 Object/Relational Mapping ，比较典型的特征就是你只管操作对象框架会帮你把对象的变更映射到数据库，mybatis 本身只是存放 sql 不存在有时候连表对应的对象可能都不会存在，mybatis plus 才是 orm ，而如果要说到更纯正的 orm 还要用到 Active Record 模式，像 python 中的 SQLAlchemy 、c＃的 Entity Framework 都是比较纯正的 orm 。

国内 Mybatis 可能是培训机构、视频啥的带起来的。哪里有统计数据可以表示在国外没人用 Mybatis 。StackOverFlow 发帖数量感觉只能表示开发人员对 JPA 的疑惑更多。Github 的 issue 数量？Mybatis 框架是国外的人开发的，SpringBoot 虽然没有专门指定 Mybatis 的版本，不过 start.spring.io 创建项目时可以选择 Spring 推荐的 Mybatis 版本。另外还有一个区别于 Spring Data JPA 复杂概念而开发的简化版本 Spring Data JDBC 项目，它的文档里也有描述怎么与 Mybatis 集成，感觉应该不至于国外完全没人用吧。说起来如果有人不喜欢 Mybatis Plus 更喜欢 Spring Data JPA 那种风格，又想要 Mybatis 灵活 SQL 的可以试试 Spring Data JDBC ，可以说是 Spring 官方的 Mybatis Plus 了。

所以我那个并不完善，也许可以实体类和 map 共存，并且互相转换，比如大量需要用的时候就用实体类，而只是一个简单的接口，那就没必要新建一个 vo 了