关于 mybatis 的疑惑

[gomorebug]

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

[m0unta1n886]

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

[Leviathann]

感觉不如 nextjs react component 里调 sql

[cslive]

我也不懂，明明 List<map> 直接输出的，为啥建一堆 vo,entity

[Aresxue]

配置一堆层是指 mapper 、dao?
纯用 mybatis 的人不多了，现在基本上都是用 mybatis plus ，单表增删改查用 baseMapper 复杂的才会用 xml ，这玩意你就理解成是个专门存放 sql 的地方，古早时期 sql 都是混在 java 代码里面的，后来发现维护太麻烦了（比较重要的原因是当时没有多行字符串这个语法糖）就想把 sql 和代码区分开，mybatis 选取了当时流行的 xml 格式使用 ognl 作为动态能力的补充，确实解决了代码和 sql 分离这件事情，只是到了现在 xml 人人喊打，ognl 表达式也略显笨重所以质疑声此起彼伏，但叫归叫其它能取代它且稳定好用的框架暂时还没出现。
歪楼：mybatis 不是 orm ，java 的 orm 月经帖太多了，目前的几款 orm 如 mybatis plus 、jpa 、hibernate 都有各自的问题，我对此比较悲观除非有 C#那种强大的语法糖，一款非常好用且完备的 orm 在 java 里可能很难诞生了

[weijancc]

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

[Bingchunmoli]

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

[msaionyc]

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

[summerLast]

数据库建模，上手简单，会写 sql 就能用，没有太多魔法


额，为啥不用 jdbcTemplate 呢，，，

[RedBeanIce]

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

[RedBeanIce]

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

[chaleaochexist]

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

[SoviaPhilo]

如果说手写 SQL 舒服的话， 哪个不支持 native Query
裸写 SQL 根本就不能算 mybatis 的优势

mybatis 用的人多完全就是因为阿里系在用这个，然后带起来的

目前我这里的感受是：
数据访问层一般情况下只负责最基本的 CRUD ， 业务行为放在领域中，
这样这个项目才有可能控制得住
一旦让写了两三年的小兄弟放飞自我，什么牛鬼蛇神都写得出来

[dayeye2006199]

感觉这玩意儿根本不是 ORM

[ionfev]

MyBatis 和 MyBatis-Plus 的缺点

借用别人的观点：dao 层和 sevice 层交叉混用。

比如一个用户查询，用 UserMpper 查询也行，用 UserService 查询也行，想用哪个用哪个。

----对比 JPA----

MyBatis 允许开发人员自定义 SQL 语句，适应特定的业务需求。

JPA 更倾向于使用命名查询和基于方法名称的查询，可能在某些情况下不如自定义 SQL 灵活。

JPA 不鼓励写手动写 SQL 语句，鼓励要用 JPQL 。使用原生 SQL 时可能会失去一些 JPA 提供的跨数据库的抽象和便捷性。

对于开发时表结构改来改去的时候，手写 SQL 方便。

当业务逻辑复杂，使用 JPA 生成的 SQL 也复杂到让人看不懂的时候，手写 SQL 直观灵活方便调试。

[Masoud2023]

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

[ZeroDu]

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

[summerLast]

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

[dc2002007]

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

[summerLast]

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

[cvbnt]

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