还是在那个大厂做项目的过程当中，甲方架构师力推Hibernate/JPA，极力反对MyBatis,在这里，我并不想比较JPA与MyBatis的孰优孰劣，这种低层次的比较，就跟比较Java、.Net、PHP、Python、React、VUE等语言孰优孰劣一样，离开使用上下文，说哪个语言是最牛B的语言，只能说自己too native,too young。
就低代码开发而言，我真的不喜欢JPA，就拿最常用的Excel数据上传来讲，Excel表格数据上传，最常用的就是POI，但是POI有个问题，就是性能不佳，Excel数据超过30万，就会内存溢出，虽然也有很多别的技巧，例如采用异步调用等等，但总是有各种各样的问题。所以寻来寻去，就看到了阿里巴巴的开源项目，easyexcel，下载后试用了一下，性能确实就如其宣称的那样强劲，也宣称支持百万条记录以上，所以非常满意。但是将其应用到项目当中时，发现 easyexcel 有个很大的问题，就是其接口支持的形式是：
List data = EasyExcelFactory.read(is, new Sheet(1, 2, Xhd.class));
那个Xhd.class就是自定义的ValueObject或者Entity实体类，跟表结构一致或者自定义的值对象或者O/R Mapping对象，为啥我说低代码开发在企业软件开发中的应用要忘记O/R Mapping呢？企业应用开发，往往表结构很多，很复杂或者很随意，比较动态，虽然针对某个企业来讲，表结构设计好后，很少会在大规模改变，但是代码在从项目往产品转变，或者在做下一个客户的下一个项目时，表结构就千差万别，完全不一样了。如果这里绑定死了某个Entity的名字，那么下一个项目该段代码就得完全重新开发，那就不是低代码开发了，就是完全订制化了。
而使用MyBatis，我们完全可以动态注入SQL，而不是绑定死表结构或者绑定死O/R Mapping对象。虽然 O/R Mapping对象我们也可以采用生成器之类的工具虽然生成这些对象，但是我确实也不喜欢纯粹为了O/R Mapping而 生成一大堆无意义的Entity。 也许Hibernate/JPA也支持动态注入 SQL而我不知道，即使真的支持，这也与 Hibernate/JPA=O/R Mapping工具的初衷相违背，失去了初心，使用它就是其门绝技了，不值得提倡。