本文主要是介绍还在手写CURD代码？这三件套任意一套都能免去手写CURD确定不来看看？——JPA+MP+TK 免手写CURD三件套，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
JPA+MP+TK CURD三件套——通用CURD神器
- JPA+MP+TK CURD套装职能对比
- JPA职能分析
- MP与TK职能分析（两者类似）
- JPA+MP+TK CURD套装性能对比
- JPA+MP+TK CURD套装功能对比
- JPA+MP+TK CURD套装使用
- 使用方案推荐
为新手朋友提供的友情链接：CURD百度百科 // 什么是CURD
解释：JPA+MP+TK 分别为：
JPA: Spring Date JPA
MP: Mybatis-Plus
TK: TkMybatis
- 只要用过上面的任意一种组件，我相信你会在这篇文章有所收获。
- 没有用过也不要紧这，这三件套任意一套都能让你省去很多手写代码，直接开发核心业务。
同步项目地址
- Gitee
https://gitee.com/zhimao/Curd- 点此直达
注：以下对比皆在完全使用该组件时提供的相对参考，即在完全用到某个单一组件功能的大部分特性时所做出的对比。文章后面会提到套装组件的结合使用方案，但以下套装对比不包含在内
JPA+MP+TK CURD套装职能对比
执行速度：很快>快>一般>慢>很慢
难易程度：容易>简单>一般>困难>麻烦
注：以下对比分析大多是从开发应用场景大小的表数量来分析，较为客观，其它因素可自行理解分析并选择套件开发
JPA职能分析
（执行速度,难易程度） 前期（速度,难易） 过程（速度,难易） 维护（速度,难易） 小型单体应用（0-10张表） 很快，容易 很快，简单 快，容易 小型单体应用（10-20张表） 快，容易 快，简单 一般，容易 小型单体应用（20-30张表） 一般，一般 一般，简单 一般，一般 中小型单体应用（30-40张表） 慢，困难 慢，一般 一般 ，困难 中小型单体应用（40-50张表） 很慢，困难 慢，一般 慢 ，麻烦 中型单体应用（50+张表） 很慢， 麻烦 慢， 困难 很慢， 麻烦 效率低原因（主观）：表数量影响前期关系关联量、代码构建、后期应用维护
MP与TK职能分析（两者类似）
（执行速度,难易程度） 前期（速度,难易） 过程（速度,难易） 维护（速度,难易） 小型单体应用（0-10张表） 一般，一般 很快，容易 快，简单 小型单体应用（10-20张表） 一般，一般 很快，容易 快，简单 小型单体应用（20-30张表） 一般，一般 很快，简单 快，简单 中小型单体应用（30-40张表） 慢，困难 很快，一般 快，简单 中小型单体应用（40-50张表） 慢，困难 快，一般 快，简单 中型单体应用（50+张表） 慢，困难 快，一般 快，简单 效率低原因（主观）：表数量过少影响整体开发效率
- 职能对比总结：起到绝对影响的是项目规模，在小型项目上采用Jpa开发更快更高效，而Mp和Tk同属于Mybatis，故Mp与Tk在其它条件相同的情况下的效率主要差异还是来自组件本身。排除这些因素单纯的就应用开发的表数量来说中大型应用的确不适合使用Jpa开发，而Mp与Tk理论上更适用于中大型项目，其开发与维护都相当便利。
JPA+MP+TK CURD套装性能对比
测试场景：同一张表的数据操作速度
测试项目：新增/更新数据、根据ID删除、根据ID获取、Excel批量导入、全部删除、全部列表
测试数据样本为其它模块生成数据，不影响该测试，以下性能测试的其它环境基本一致，同时在API文档中进行测试，主要的测试过程省略，以下为真实统计的性能测试效果
测试平均耗时
测试用例 JPA MP TK 新增更新 平均55ms,去除首次平均30ms 平均47ms,去除首次平均31ms 平均44ms,去除首次平均27ms 根据ID获取 平均41ms,去除首次平均18ms 平均19ms,去除首次平均15ms 平均18ms,去除首次平均16ms 根据ID删除 平均28ms,去除首次平均22ms 平均32ms,去除首次平均28ms 平均25ms,去除首次平均23ms Excel批量导入(1000条) 首次1330ms,去除首次平均510ms 首次3105ms,去除首次平均3000ms 首次753ms,去除首次平均212ms Excel批量导入(10000条) 平均4s 平均30s 平均1249ms 全部列表(1000条) 首次213ms,平均100ms 首次127ms,平均80ms 首次113ms平均79ms 全部列表(10000条) 暂不测试 暂不测试 暂不测试 全部删除(1000条) 平均30ms 平均3s 首次3s,去除首次平均2s 全部删除(10000条) 平均51ms 平均29s 平均29s 总结：JPA在数据的增删方面速度较快，其数据量越大效果越为显著，故Jpa的应用场景必然是小项目大数据的快速开发才能发挥出极致的作用。Mp和Tk大同小异，他们的优点就是维护，这点在大型应用上是必不可少的阶段，中大型项目必然首选项。
JPA+MP+TK CURD套装功能对比
JPA主要服务接口预览
MP主要服务接口预览
TK主要服务接口预览
总结：在主要服务接口上，Mp阵列明显较多，在大型且复杂应用业务中有明显的优势。就应用场景而言，小中大的单体应用采用顺序考虑采用（Jpa-Tk-Mp）为最佳。当然，每个应用都有不同的业务需求，具体的开发选择，还得根据事实而定。
JPA+MP+TK CURD套装使用
- 具体参考源代码
同步项目地址
- Gitee
https://gitee.com/zhimao/Curd- 点此直达
测试数据部分内容
通用接口预览：
- 更多使用请参考项目文档
- 10000条测试数据可在公众号回复【CurdTest】获取：三千IT屋
使用方案推荐
以下大致说明，并非详细描述，部分表达省略请忽视
- 规范化开发——需求->设计->开发 （流水进行）
- 学习型开发——需求+设计+开发 （同时进行）
- 规范化开发——采用（JPA->TK->MP(按应用规模适当选择)）JPA小型，MP与TK大型
- 学习型开发——采用（JPA+MP）双向结合适合学习中的开发
- JPA+MP结合下篇再发例
- 学习型开发意指学习java的其它层面的操作如Shior、Jwt鉴权，缓存，云存储，反射原理，Aop、IOC编程等，它为你在学到新的东西需要向数据库作出更变操作时提供便利。
这篇关于还在手写CURD代码？这三件套任意一套都能免去手写CURD确定不来看看？——JPA+MP+TK 免手写CURD三件套的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
