abel533
commented
1 year ago 加Q群：277256950
提供 service 主要是针对不同层次的用户。
tk 和 mybatis-mapper 中的 Mapper 最适合的用户是有一定封装能力的用户，可以自己组合想要的接口（mybatis-mapper更灵活），自己封装Service，方便自己框架用。
现在也有很多初学者或者能力欠缺或者懒的用户，只能用现成的，不提供就不会用，所以提供更多的封装。
crazyweeds
一天内我从tk切换到mp，再从mp切换到mybatis-mapper。再说下我的情况，tk我大概使用了4年左右，从开始使用就自己封装了通用Baseservice和BaseServiceImlp。
为什么放弃tk：tk的api命名设计遵循了官方MBG，这点非常不错，使用起来心智负担很低。但对于一些条件查询，又只能使用Example，Example的使用体验极差，也不够优雅，如果表字段出现变更，那真的是灾难，所以尝试换mp，而且mp在批量处理上面占优势（包括对比mybatis-mapper）。
为什么放弃mp：mp在复杂查询的时候，还是非常不错的。但api设计真是灾难，心智负担极高。比如update、insert，默认就是过滤null，如果我需要不过滤null，需要统一设置，这就是天坑（明明可以通过不同方法名降低心智负担）。并不是所有业务都要过滤或者不过滤。而且所有简单查询都要Wrapper包装，有种脱裤子放屁的感觉，你明明知道我要update，你就不能底层Wrapper一下,重载一个方法，让我直接扔entity对象进去？就感觉mp的作者没体验过tk，所以搞出一堆复杂的逻辑出来。曾经一次和一个多年经验的同事聊，感受和我差不多，至少从我和同事的角度而言，是坚决抵制mp的。心智成本太高了！
为什么选择mybatis-mapper：因为tk几乎不更新了，tk查询局限性确实太强了，虽然可以Example，但lambda相比Example真的强上了太多了，而且api命名设计比mp强，但感觉没有tk好。一些想吐槽的地方，mybatis-mapper说明页需要增加很多注解。选型的时候，就会产生门槛，你对我的代码入侵太多了。属于没上船，就走了，体验的机会都没有，大忌。就像某些人对swagger有偏见，他们觉得swagger需要太多注解了(知识储备问题，其实只使用基本注解也能正常工作)，感觉这点可以参照swagger。 一个建议啊，其实service层命名可以和mapper一致，降级一些心智负担。mp的槽点就是mapper方法设计+service方法设计都很糟糕+null处理机制（其实可以通过不同方法名规避）。 通用service的初衷是什么？我自己当时的初衷是：OrderService里面注入了UserService，我自然不想再注入UserMapper，为了优雅+偷懒。但如果userService和userMapper方法名不一致，期望和实际劈叉了。同样，我学了mapper的通用方法，我还得学一遍通用service的方法，而且BaseMapper.a和BaseService.b的作用是一样的，就有点尴尬了。
尝试推导：我们真的有必要findOne和selectOne吗？答：为了区分service和mapper。问：用类名区分不更好吗？
主要是感受，言辞可能有不得当的地方。无论是对mapper还是mp，并不是为了贬低，而是为了更好。