Wrapper不止处理字典，还有其他各种模块的都会处理到，如果你用了dict注解，涉及到其他模块，还是需要走wrapper才行，没有必要。
如果加上了各种注解全自动实现，又会有用户说封装太深看不懂，所以这个目前是不考虑开发的。
而且wrapper内可以写复杂逻辑和返回，更加自由。
可以考虑加上注解，但是手动调用的方式不？这样关联业务表的数据查询可以满足90%的业务
这样手动调用一下，VO中的注解关联业务表的查询就去执行了，和Wrapper差不多，就是开发效率上更快一些
这种定制性、风格性、封装度太强，还要去翻文档学习怎么使用，不适用于所有用户。
而一个言简意赅的wrapper不需要翻文档，接手的人一看就明白。
还有注解形式限制太大，破坏代码风格，新接手的人难以迅速看懂，后期上线调整逻辑和维护会很麻烦，所以不考虑了。
也就是我要关联业务上其他表的数据，只需要在Wrapper里重写PageVO或者ListVO就行对吧？
wrapper主要还是针对缓存类、不怎么变动的数据进行的查询和赋值。
如果涉及到join查询则不建议用wrapper解决，建议手写sql查询或者用mybatis-plus的join组件来实现联动查询。
比如处理字典、用户、部门、角色这类基本不变动的，可以通过他们的缓存类，在wrapper快速匹配赋值。
如果是n个连表查询，就不适用wrapper了，还是需要写join条件来查询。查询返回结果后，剩下的字典、用户这类再用wrapper处理。
比如列表查询需要关联其他业务表的数据，是否可以在Wrapper里SpringUtil.getBean,进下查询一下，这样是分页量数据的查询，而不是全量的查询，会不会更合适呢？
除非你做了缓存，或者本来join查询10秒，单独在wrapper新开局部查询只要1秒，有这种巨型提升的情况下可以，其他情况不推荐。
不然每一次分页10条数据，就要有11次数据库查询，在高并发场景下数据库扛不住的，平白多了n倍压力。
我想这样：在Wrapper里重写pageVO,这样一页的数据一个查询就搞定了，不在entityVO里每条数据都查一下，这样是否可行？比写关联sql查询要快的吧？代码生成出来，page分页不用改代码，直接Wrapper里加下业务查询就可以了？我这样设想的。
加载中...
苏公网安备 32041102000998号