头条上问这种问题也是醉了。。看到了顺便答一波，瞎扯的人太多。
国内的设计思路是table driven的，简单来说，用数据表定逻辑，用模型做实现，实际这是和面向对象相反的思路。mybatis所谓的灵活性在大多数工程师手里就是不用考虑模型如何设计，“反正我用原生sql都能解决”，模型设计的烂的一逼，全靠sql去修修补补。而jpa是完全object driven的思路，前期设计的缺陷会很制约后续开发，并且不同的数据库可做不同的实现（实际是哪怕是redis也是一样的）。回答几个常见sb问题。
1.jpa表连接行为不确定，难以控制。
你确定你用过spring data jpa？不知道有EntityGraph ？傻瓜到这种程度了还能咋的。
2.jpa子查询不好实现。
我估计你都没用过吧？spring data jpa的子查询既可以多带带定义视图，也可以做subquery，甚至直接用jpql。
3.jpa不好优化。
我真不信99%得优化能超过spring data jpa的优化，尤其是一般般的程序员能别把优化放嘴上么，连mysql的锁都搞不清楚，表设计的跟坨屎一样还天天原生sql，觉得自己很牛逼么？jpa是可以把表属性反应到对象的，天然就有运行时优化的底子在，ORM能发展的空间太大了，稍微有点技术认知的都知道ORM会优势越来越大。稍微有些经历的程序员都知道现在是先说好维护才说其他的，能解决性能的方法太多了好么。
最后，难道不知道现在提倡ORM+CQRS么？请问，有啥复杂的解决不了，都不需要native sql介入好么。
评论0
加载中...
个人认为mybatis可以做到代码与SQL解耦，单表查询用jpa倒是没什么，要是写统计或者复杂查询之类的jpa就不太友好了，需要代码逻辑跟SQL耦合起来，代码可读性和可维护性不好。最近基于jdbcTemplate做了一套自定义动态查询，也将sql放在了配置文件中，也是为了降耦和提高代码可读性，还可以根据业务场景定制很多功能。
评论0
加载中...
这个问题需要真实去使用过，在使用的过程中会发现各自框架的痛点，当你寻找解决方案的时候，你会看其它框架有没有解决这个问题，这样你就会领悟到另一个框架的优势了。
分享一个真实的实战经历：
项目刚开始使用原始JDBC方式操作数据库，自己手动建表不说，手动组装对象太痛苦，表字段和对象的关系映射写一堆代码，这时候就会想如果有个框架能自动把表和对象关系自动映射，并且能够封装好使用方法，在初始化时还能自动建表就更好了。
查找方案时发现了SpringDataJpa，仿佛打开了新世界的大门，原来通过写SQL查询再转成对象的增删改查都不用写了，表字段和对象的映射也不需要手工写代码去匹配可，直接使用，而且可以开启初始化时自动创建数据库表。原来需要消耗时间的数据库操作代码现在完全不用写了，简单的条件查询，直接调用封装的方法，快到起飞。但是随着业务数据的不断增多，要查询的条件也越来越复杂，查询时效越来越慢，渐渐对查询性能也有了要求。然后就想，在这样的使用便利上，如果有能便于优化数据库查询性能的解决方案就好了。
再次找解决方案，发现了MyBatis，感觉发现了另一个新世界。虽然，它不能直接把表和对象的关系映射自动封装好，但是它可以直接把操作结果映射成需要的对象，只需要建立对应的数据对象DTO就行，并且多表关联查询、复杂条件查询都可以写SQL解决，最重要的是SQL和逻辑代码分析，维护也很方便，SQL优化交给专业的DBA就行，再次好用到起飞。
突然有一天，公司强制要求数据库从oracle换成MySQL，发现Mybatis因为都是写的纯SQL，原来的SQL语法是oracle的，现在都要改，太依赖数据库了，不便于换数据源。这时想起了不依赖数据源的JPA。
总结一下个人看法：
JPA使用完全面向对象的的设计思想，一个表就是一个对象，所有的操作直接操作对象就行，方便、快捷，也不需要关注底层数据源问题，但是表之间的关系复杂了、查询复杂了，这样的操作不是它的强项。
Mybatis是半面向对象、半面向SQL，SQL与逻辑代码分离，查询结果映射成对象，所有操作上层是对象，下层用SQL，数据查询优化上更加实用，因为是写原生SQL，所以换数据源可能麻烦。
还是业内的那句老话，没有绝对“银弹”，只有适合当前业务发展需要的技术。
评论0
加载中...
评论0
加载中...
看了一些其他人的回答，喷子蛮多的，喷了轮子还不够还要喷别人sb，不会用。没必要搞歧视，都是轮子，用来解放生产力的。轮子好不好，根据具体场景来。
但是从普适性上来看，如果本来比较简单的事情，用了工具之后反而更复杂了，那就应该反思了。没错，这里我说的就是jpa。
Jpa确实很多概念都不错，如果你拿它做个Demo，会发现确实是生产力解放工具，一旦你用到真实项目上，可能就不尽人意了。除非你的项目业务很简单，不涉及复杂的表关系，因为在单表的模型上jpa确实表现得很优雅，但是哪个实际的业务会如此简单？做过项目的人都有经验，不用我多说。
看到这里，很多人就会喷了，Jpa你会不会用呀，querydsl，enetitygraphql，hql这些都可以用来做复杂查询，你用过没？
嗯，其实我现在就在用这些东西。这些东西确实能解决问题，但也只是解决能不能的问题。这就回到前面我所说的，本来简单事情，反而因为工具更复杂了，原来只用写sql就能解决的问题，现在是不用写sql了，但是得写所谓hql，dsl，graqhql，这就造成你不光要搞懂sql怎么写，还要搞懂用这些玩意怎么去间接生成你想要sql。
其实用上面这些和jpa捆绑在一起的东西的，本身就是jpa短板导致的无奈之举，这些东西本身和jpa理念是互相矛盾的。
说到这，有些人的言论就变成了，你不会用怪谁，水平不行怪轮子。这是混淆概念，好不好用是工具自身便捷与否，和用的人水平有什么关系。
所以，究竟jpa好不好用，得看你用来做什么了。
评论0
加载中...
两者并没有明显的劣势。从技术角度讲我更喜欢Jpa，因为她是标准，功能上会强一些。但是在企业开发架构选型上可能会选择mybatis，因为他简单上手快，半吊子程序员也能写出性能不错的代码，学习成本低，也为企业节约成本。反观Jpa能掌握精髓的人少而贵。。。。
评论0
加载中...
1、jpa 出的比较早，是面向对象的思想，一个表封装成一个对象，对单表有比较好的控制。继承，约束啊，都是面向对象的产物
2、mybatis则是面向sql，比较灵活，你的结果完全来源于sql。可以针对于单表写结果集合，也可以自己组装，想要什么完全取决于你的sql。对于复杂应用来讲比较灵活。
没有什么为什么要有，技术只是方式，为业务服务的。为合适的业务选型最合适的技术，这才是做架构的精髓
评论0
加载中...
spring data jpa在复杂查询上可以使用query+new 构造方法或者视图的方式去查询，至于说效率，我想应该是在POJO中使用@OneToMany或者@ManyToMany的注解导致的，一般情况下尽量使用@ManyToOne就可以了
评论0
加载中...
没人用 mybatis plus吗？强大的代码生成器，比jpa还爽的单表查询，同时还mybatis的xml，灵活的sql不在话下
评论0
加载中...
0
回答0
回答0
回答0
回答10
回答10
回答0
回答0
回答0
回答0
回答
