【IDEA】最好的MyBatis插件 写SQL从未如此轻松

夏Ding:
我写的一个superwrapper可以直接做增删改查，join等多种句型的复合wrapper拼成新sql，效率不低。 我查询方法一直在写一种union拼出复合语句一次性查出数据集和总数，查询效率（最快十毫秒）比官方plus双重查询（二三十毫秒）要快大概一倍，平均节约一倍的时间[脱单doge]

【回复】牛是牛，开发起来可能非常爽，但是在项目后期，接手的人会觉得非常恶心，这东西不就和queryDSL一样，像找个表在哪被调用，根本找不全，乱七八糟的，维护起来真的是头疼
【回复】回复 @666777888252 :对的，要完全依赖这类工具问题都就是一样的，和某些项目默认只用plus是一个道理。 实际情况中业务都是复杂的，默认最好是结合xml去用，包括很多复杂查询。 而且你的问题涉及到开发准则，开发人员在调用不同的表单业务时，不应该直接使用mapper和wrapper，而是统一通过对应服务层方法的Params或DTO、Vo实体传参去调用数据。把对一个表单相关的业务访问逻辑都汇聚到它自己的服务层去处理，才能根本上避免后期维护困难的情况。 a表服务层这边单独wrap一个b、c表查询，c服务层那边又单独用wrapper写一个a表的sql，这样的习惯后期一定会搞出极其恶心的维护灾难。 说到底这是开发原则问题，在任意位置随手用拼接工具写业务，是很没效率的开发做法，这样做基本已经放弃考虑代码复用的核心开发原则了吧[吃瓜]。 这和用不用工具没有关系，只和开发人员守不守一些准则或者开发经验和水平有更大关系。新人更容易滥用拼接工具。只要遵守原则，该在哪写业务就在哪写，工具用起飞了也没关系，是可以避免滥用情况的。 反之，不论用不用工具，你去维护那些随地生根的业务代码永远都是灾难。
【回复】回复 @alittlesky :实际上可能没有想象的好用，我当时做这个的初衷是业务逻辑复杂化了，心想直接在服务层用wrapper做完所有业务，要用得顺手的话是有一定的学习成本的[笑哭]，对mybatis plus熟悉就可以[doge]
真实z:
不如直接用mybatisplus加mybatisplusjoin直接不写sql[doge]

【回复】回复 @余的苦命生活 : 不清楚,我也是最近才发现的,写中小型项目用来偷懒是挺不错的和mp一样都是无侵入的,目前我整体体验还是不错的 至少不用在xml里写sql了一点提示都没写的很折磨,缺点的话也是和mp一样把dao的功能全放到service层的话确实还是会有点拥挤
【回复】回复 @真实z : 看了，感觉如果有mp的在service直接可以一路链式就好了。也还可以应该比xml舒服
史贞节:
easycode可以了解一下。可以按照你的要求生成任何你想要的结果。包括controller层也给你生成出来

【回复】我玩透了easycode，然后玩纯velocity，我甚至直接生成前端代码[笑哭] 当初为了做到和easycode大佬的理念类似，我用io写接口，在前端一键点击按钮即可本地各对应路径自动放置.java和.xml文件[doge] 爽是爽，但是现在已经迭代得过于复杂了…
【回复】再用Java写easycode里面自带的所有工具对象tool之类的注入进去，兼容了部分以前easycode自带的一些好用的语句和方法，主要还是需求比较复杂，最后为了方便索引跳转，全部代码都集中在一个vm文件。需求问题，还是有必要哈，暂时没有特别好的其它方案
【回复】是的，看需求，我现在的这版就是魔改了诺依的gencode模块
aswiftliu:
少用这些插件，用多了，就会忘记原来这些是怎么写的了

四处察察:
我不喜欢写xml，也不喜欢用plus，所以自定义了十几个MBG插件类，通过它们结合MBG用起来比plus舒服多了

【回复】回复 @秋天没了落叶 :mybatis generator 就是MBG
【回复】回复 @D1anSkr :那样没啥意思，QueryDSL+JPA 是一种更优的选择 如果需要写mbg插件，建议用freemarker模板技术，因为mbg插件写起来太繁琐也抽象，没有模板技术合适。 至于mybatisPlus，谁爱用谁用，反正我不用
芳文社副社长:
我是新手，比较奇怪为什么mybatis用的这么多。jpa有什么缺点吗

【回复】mybatis简单好用，而且适合当前的主流开发模式，可以直接返回VO对象
【回复】多表联查的复杂业务比较恶心，且对于维护人员不太友好
哎呀我怕你啊:
说真的，用mybatis的没几个新手了吧，其他都用jpa了

解小天:
如果某个表字段特别多的时候这个插件就会导致巨卡，敲一个字卡好久

【回复】回复 @时间之外的看客1111 :不用到100，几十个就卡成PPT了
【回复】100个字段的表是不是要卡很久