自己封装JDBC VS 持久化框架

Question

从jdbc到hibernate，从hibernate到mybatis，一直是麻木地跟着潮流，为了工作使用而使用

我现在有个想法，在JDBC的基础上进行封装使用jdbc+redis来进行开发，这样我自己可以按自己的想法来蹂躏jdbc

不知正式环境下，用这样的方式进行长期开发是否可行，是否存在问题？

大公司持久化框架是自己封装还是使用现成的持久化框架？

Answer 1

个人来看，自己折腾轮子攒经验还好，如果要上到生产环境就得慎之又慎了。因为这是基础工具，要想做一个在生产环境中可用的，除了具备强大的基础能力、对jdbc 的理解，还需要长久的时间打磨，经受各种生产状况的考验才行。现在各种成熟框架都是有各个公司踩坑升级才达到了如此的稳定性，自己折腾的框架隐藏的问题暴露可能需要更长的时间，然而这个一旦出问题可能就是大批量的，造成数据丢失、重复。

评估了那么多框架如果都不满足要求，并且确实了解了实现一个新的框架所需要经历的困难可以承受，那就动手去做吧。

Answer 2

自己封装没什么问题，只是是否有足够的资源与时间去做这件事。

现有的持久化框架主要功能点在于多 SQL 方言支持、多数据源配置、数据表映射（及实体字段变动与数据库表字段变动的联动处理）、缓存与自动化工具支持上。

如果业务只需要支持特定的 SQL 方言、少量甚至只有一个数据源、数据表映射的联动要求不高、不是非常需要缓存加持，那么自己封装并不是什么坏的选择。至于自动化工具支持，IDE 一般会自带一些，然后就是 SQL 拼接工具之类的东西了，只要你熟悉设计模式与目标 SQL 方言的语法，那么自己动手做也挺好的。

特别的，关于数据表映射联动，举个栗子：

@Entity
public class Student extends BaseEntity {
    
    private String name;
       
}

其中 BaseEntity 提供了基础表字段，如 id、createtime、updatetime 之类的东西，现在业务需求在 Student 中增加/减少一个字段，要求你的框架能自动识别并在对应数据表增加/减少对应字段，其中减少字段一般是直接取消对数据库表的响应字段映射即可。

然后一对多多对一之类的关联关系如何建立，联表查询的 API 形式等等，都是需要考量的。

再举个栗子，在 hibernate 中，允许通过 @Where 之类的注解来在对应字段 getter 触发时才拉取数据并应用注解值进行筛选，这种功能点是否需要以及如何去做。

公司普遍还是在现有 ORM 基础上二次封装出如 mybatis-plus 一类的东西，当然技术实力以及资源充足的组或公司会选择自行实现 ORM 中的部分东西。