在头条上问这个问题真是太醉了。。顺便说一句，胡说八道太多了。
国内设计理念为表驱动。总之，逻辑是由数据表决定的，实现是由模型来完成的。事实上，这与面向对象的思想截然相反。大多数工程师手中所谓的mybatis的灵活性是，他们不需要考虑如何设计模型。”不管怎样，我可以用原生sql来解决这个问题。模型设计太差了，只能靠sql来修正。jpa是完全对象驱动的思想。早期设计的缺陷会制约后续的开发，不同的数据库可以用不同的方式实现（事实上，即使redis也是一样的）。回答一些常见的问题。
1.jpa表的连接行为具有不确定性和难以控制性。
您确定使用了spring数据jpa吗？不知道有实体图吗？当一个傻瓜达到这个水平时，他能做什么。
2.jpa子查询不容易实现。
我想你没用过，是吗？spring数据jpa的子查询不仅可以单独定义视图，还可以进行子查询，甚至可以直接使用jpql。
3.jpa不容易优化。
我真的不相信99%的优化能超过springdatajpa的优化。特别是，普通程序员能否停止谈论优化？他们甚至搞不懂mysql的锁。表设计就像一堆废话，他们仍然每天使用原生sql。你觉得他们很棒吗？jpa可以将表属性反映到对象。当然，运行时优化是有基础的。orm的发展空间太大了。任何有点技术知识的人都知道orm将拥有越来越多的优势。有一点经验的程序员都知道，在谈论其他人之前，是时候先谈论良好的维护了。解决性能问题的方法太多了。
最后，难道你不知道ormcqrs现在是提倡的吗？请问，有没有什么复杂的问题没有原生sql的介入是无法解决的。
个人建议：mybatisplus为mybatis做了很多改进。简而言之，hibernate的优点，mybatis=mybatisplus的优点，增强了mybatis改变数据库时sql的兼容性（hibernate的优点和mybatis的缺点），封装了一些简单的sql（hibernate的优点和mybatis的缺点），从而在不降低性能的前提下提高mybatis的开发效率。mybatisplus与mybatis兼容，但发电机除外。新项目可以根据项目情况使用，旧项目不需要抛掷。运行项目通常首先是稳定的。如果你完全负责一个新项目的后端，你可以使用你想要的任何东西。如果你是一个团队，你必须讨论它。作为一个开发人员，这不是胡说八道。你必须两者都知道。该项目可优先考虑plus。
springboot，
hibernate，
datajdbc，
mybatis
更多，您可以关注dingo。
根据mybatisplus的设计模式，那些接受conditionalor和wrapper参数的方法就是conditionalorwrapperobject的参数
！在您的示例中：用户映射器.selectone（newquerywrapper<user>（）.eq（”user）此映射器方法属于dao层。它接受从服务层传递的对象querywrapper。你认为你有一种心态用户映射器.selectone（newquerywrapper<user>（）.eq（“userage”，age）作为一个整体是一个dao方法，不是
用户映射器.selectone（），您只需要自定义所创建的包装器对象。
记住：方法是一个参数，不是别的。
mybatis是ibatis的升级版本。访问数据库的两种形式是不同的。mybatis没有daompl层。通过sqlmap接口直接访问数据库。我不认为我们能支持它。方法是不同的。我认为mybatis比ibatis更容易使用，也更方便。
