[發明專利]持久層代碼的生成方法和裝置

有效

• 申請號: 201210067610.4
• 申請日: 2012-03-14
• 公開（公告）號: CN103309650A
• 公開（公告）日: 2013-09-18
• 發明（設計）人: 鄧旻輝;羅坤莉
• 申請（專利權）人: 阿里巴巴集團控股有限公司
• 主分類號: G06F9/44
• 分類號: G06F9/44;G06F17/30
• 代理公司: 北京康信知識產權代理有限責任公司 11240
• 代理人: 吳貴明;江舟

技術領域

本申請涉及計算機領域，具體而言，涉及一種持久層代碼的生成方法和裝置。

背景技術

在企業應用大量興起的今天，各企業為滿足消費者的各種需求，每天都必須進行大量的應用開發，從而導致一方面開發的代碼量迅速膨脹，另一方面，雖然這些應用開發的內容有所不同，但是經過長期的開發可以發現，許多代碼都是極其相似的，尤其是持久層。

特別是對于J2EE應用的開發，長期以來，由于程序框架通用的三層架構(持久層、業務層、展現層)在各個公司被奉為經典，各個公司基本全部采用這一架構，在這一架構中，在代碼的下層，數據存儲的方式，由最初的關系型DB到cache、KV、NoSQL以及面向對象數據庫等，概念層出不窮，但關系型數據庫仍是絕對的第一選擇。

在程序框架通用的三層架構中，各公司的業務的不同直接表現為業務層和展現層各有不同，持久層操作數據庫是基本相同的，對于關系型數據庫而言，持久層做的任務操作都沒有超出CRUD操作的范疇，只是操作的復雜性各有不同，因此，使用工具將數據庫表實現為持久層代碼，在理論上是完全可行的。

當前，在J2EE項目中，根據持久層采用的底層技術不同，持久層代碼自動生成的實現方案主要分為三種，一種是基于原生的jdbc實現的，一種是基于Hibernate實現的，一種是基于Ibatis實現的，總體來說，在大型應用中，后兩種是使用最廣泛的框架。另外，根據采用的數據庫交互技術不同，目前也已經有許多不同的持久層代碼自動生成的實現方案，例如：

1)MyEclipse等軟件提供了用戶選擇數據庫表，然后自動生成基于Hibernate框架的DO(Data?Object)、映射文件、DAO(Data?Access?Object)文件聲明與實現，在場景較簡單的情況下，這種持久層代碼自動生成的實現方案完全符合需求。

2)對于Ibatis框架，目前做的比較好的是Ibator，通過xml文件制定數據庫連接、用戶名、密碼以及表名稱等，根據數據庫連接、用戶名、密碼以及表名稱等就可以為每一個數據庫表自動生成代碼，該代碼主要包括sqlmap文件、Data?Object文件、DAO文件聲明與實現。

以上兩種代碼生成，都提供比較好的便利性，用戶在簡單操作的情況下，就可以獲得可用的代碼，論其原理，總體來說，都是通過獲取數據庫表的元數據：字段名、字段長度以及字段長度等系列屬性，進行映射，將數據庫字段名轉化為駝峰類型的Java類型變量名，并按照數據庫類型和Java類型的映射關系，按照生成一系列的文件。

但是，上述的兩種主要的代碼生成工具也都有著比較明顯的缺點，例如：

對于1)種持久層代碼自動生成的實現方案而言，Hibernate框架在復雜需求場景下比較糾結，程序員必須通過一種HQL(類似SQL語言，最終執行時會轉化為SQL)語言才能進行數據庫操作，因此，用戶在進行類似開發時，需要另外去掌握HQL語言，編寫大量的代碼，而且，在剖析程序獲得數據的過程中，最終還是需要在關系型數據庫中執行SQL語句來獲得數據，然而，如果這些SQL語句最終不被用戶所知是非常危險的，另外，在現在的企業應用中，整個應用最大的瓶頸就是數據庫，有時候，一句效率低的SQL就可以讓數據庫宕機，導致應用也跟著宕機。

對于2)種持久層代碼自動生成的實現方案而言，Ibatis對ORM封裝粒度較低，開發人員可以自己掌握SQL語句，SQL語句的執行效率比較有保障，但是，為滿足所有的業務場景，Ibator在自動生成代碼時使用Criteria來支持所有條件查詢等工作，為滿足可能的復雜查詢需求(其實即使如此，也沒能實現所有的需求)，Ibator按照全羅列的方式來進行支持可能的復雜查詢需求，導致了代碼急劇膨脹的問題，例如，一個100個字段的數據庫表，一個支持類的代碼接近5500行，這對于后續維護來說，簡直就是一個災難，也就是說，一個應用如果有大量代碼沒有使用，而且又保留起來，這樣做不僅浪費存儲空間，還很有可能在長期的維護中，造成巨大的問題，從而增加維護代碼所使用的系統資源。

發明內容

本申請提供了一種持久層代碼的生成方法和裝置，以至少解決相關技術中由于持久層代碼冗余較大而導致的浪費存儲空間的問題。