MyBatis还是JPA? 终于有答案了!
发布网友
发布时间：2024-10-02 04:05
共1个回答
热心网友
时间：2024-10-19 14:30
虽然技术选择应考虑需求，但团队技术水平也是关键。若选用高级技术，可能给团队带来困扰。
JPA抽象层次高，代码简洁，但实则复杂。尽管多次培训，我所带领的团队在使用JPA时仍感棘手。
我放弃使用JPA，原因如下：
并非JPA本身不佳，而是它并不完全适应我国国情。若要在公司推行JPA，需有稳定的产品团队和强大的技术团队。
因此，大多数公司宁愿编写繁杂的MyBatis代码，也不愿尝试JPA。这符合逻辑，遵循事物发展规律。
接下来，我们将讨论MyBatis，探讨如何编写优雅的MyBatis代码。
优秀程序员都追求便捷。许多人不愿设计实体的SQL语句。JPA可依据Java实体代码生成库表SQL，这是MyBatis用户所羡慕的。
使用MyBatis，需先设计库表，再反向生成Java代码和配置文件，如mybatis-generator所示。
但请注意，mybatis-generator有四种模式，初学者应关注第一种模式。
以下仅介绍MyBatis3模式的代码生成。
使用它，需在pom.xml中添加依赖。
我倾向于使用Java代码操作代码生成过程，以下为生成代码的示例。
从代码中可见，需配置generatorConfig.xml文件，规定代码生成规则。
运行MBGTool文件后，即可生成MyBatis代码。
但请注意，这种模式并非最佳选择。它生成大量无用文件，可能导致代码质量问题和覆盖率问题。
经过多年摸索，我推荐一种更实用的写法。
第一、无需代码生成器。
数据表设计和domain编写均手动完成。若需迁移至JPA，此模式可学习Java数据类型与SQL数据类型的对应关系。
第二、无需编写映射文件。
直接手写Mapper文件，声明所需接口方法。
例如，在AccountBasicMapper目录下的insert.sql文件中，可书写具体的SQL语句。
此语法如何配置？需引入MyBatis脚本语言配置功能，使用freemark模板。
别忘了添加依赖，并在yaml文件中进行相应配置。
这种模式有诸多好处。
当然，也存在缺点。
但我认为这并非问题。每个方法配备一个SQL文件，代码编写更简单。当出现问题时，可快速定位并修改对应的SQL文件。
个人推荐此模式，并在团队中推行，效果良好。
此外，为减少重复SQL代码，程序员在设计Dao接口时会更加认真。
