現在流行的對象關係映射技術產品得以存在，它們能被大的服務器提供商（包括IBM等）認可，它們有很多優點，這是不可否認的。對象關係映射技術產品使用XML或依賴注入的方式實現數據庫結構的映射，這種思維方式已經固化了，已經被被奴化的架構師們、被奴化的碼農們、被奴化的獵頭們、被奴化的項目經理們普遍的接受，過去很少有人懷疑過。但是，我個人認爲這種方式不科學、不合理，我相信有此同感的人不止我一個。原因有以下幾點：
數據庫的結構信息被人爲地物理地重複定義一遍，系統架構變得複雜，軟件工程文檔的數量成倍增加；如果沒有這種重複的物理的數據庫結構定義，它們什麼都幹不了。
軟件產品維護困難，如果需要修改數據庫的結構，就必須修改XML映射的定義或者修改注入，這給修改Java源代碼人爲地增加了一道由中間環節帶來的困難，而在整個系統的實現過程中，數據庫表的結構變化是很正常的，可能會是頻繁的；如此折騰，給整個軟件工程帶來的額外的工作量是非常大的。
如何改善基於流行ORM產品的軟件工程的效率，伴隨這一問題的ORM產品的衍生產品應運而生，這是技術的進步？還是人力、技術、財力等資源的浪費？還是ORM產品帶來的不是問題的問題？這些爲ORM產品服務的衍生產品主要的任務就是配置XML映射文件。
重複定義數據庫結構信息，根本上就是一種錯誤的決定，是上述不合理性的根本原因。JDBC是各大數據庫供應商共同遵循的標準，而數據庫的結構信息對於JDBC來說完全是透明的，XML映射、注入映射完全是多餘的畫蛇添足的作法。
如果你是系統架構師，在使用ORM產品解決以下問題時，請問該怎麼做？
怎樣查詢數據庫的結構信息？
怎樣實現兩個不同數據庫之間的數據交換？
客戶需求變了，數據庫的表的結構變了，需要修改那些軟件工程文檔？需要修改那些源代碼？
對於以上問題，如果任由你自由發揮，你又會怎麼去做？
以上問題並非虛構，而是非常有現實意義的問題。如果在我們的軟件設計過程中，能方便的查詢數據庫的結構信息，就可以智能化的處理數據的CRUD操作，比如：自動過濾掉無效字段，只提取有效字段，並將有效字段保存到數據庫中，否則，會異常。對於兩個不同數據庫之間的數據交換，不需要依賴XML映射、不需要注入映射，那該有多好，這樣就可以方便地實現數據庫的遷移、數據的備份等等。客戶需求變了，表的結構變了，我們不需要管那麼多的XML映射、注入映射，只需要修改局部的Java源代碼，那該有多省事。
ORM產品，我們差不多已經使用了十年，有多少成分是客觀的選擇、理性的選擇？有多少成分是盲目的選擇？
科學技術的進步需要我們打破墨守成規的思維，應當學會用實事求是的精神去面對別人給我們規劃的條條框框，尋求開拓創新。只有這樣才能更好地促進中國軟件技術水平的進步，中國的軟件技術才能更多地爲世界做出貢獻。