還是在那個大廠做項目的過程當中，甲方架構師力推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工具的初衷相違背，失去了初心，使用它就是其門絕技了，不值得提倡。