由代碼生成數據庫結構，保障設計正常傳遞到實現

咱們經常使用代碼生成工具來生成表結構。爲何不試試從代碼來生成數據庫表結構呢？

這個觀點有些匪夷所思，可是熟悉Hibernate的同志應該有所體會。Hibernate有一個功能，叫作hbm2ddl,在系統啓動時，Hibernate掃描hbm映射文件，檢查數據庫結構和hbm是否匹配，若是不匹配，則在數據庫中增長hbm文件中描述的表或者字段。嚴格意義上來講，這不是從「代碼」生成表結構，而是由「hbm配置文件」生成表結構。後來，當Hibernate支持註解功能後，hbm2ddl也會自動掃描EntityBean上的註解，來與數據庫表結構進行匹配。因此，這個hbm2ddl，也算做從代碼生成表結構。

回到原點，爲何須要從代碼生成表結構的功能？

咱們通常的開發過程，是先作了「數據庫設計」，而後在數據庫中建表，最後再編寫java代碼。數據庫設計工具，通常提供生成表結構到數據庫的功能，也提供生成和表結構對應的javabean功能。

【數據庫】<-【數據庫設計工具】->【JavaBean】

若是咱們的數據庫一次成型，永不改變，每一個版本只作代碼層面業務邏輯上的變更，那麼上面的過程是比較完美的。

但實際上，做爲一個長期維護的軟件系統，數據庫設計不變更，是幾乎不可能的。那麼，當開發下一個版本的時候，咱們首先須要變更的是數據庫設計文件，而後在開發環境中，變動表結構，而後在源代碼中，變動JavaBean的定義。

假設咱們用到的數據庫設計工具很是好,那麼咱們能夠用它對比新的設計文件和舊的數據庫結構及代碼的差別來達到設計與實現同步的目的：往數據庫方向，能增長表和字段，往JavaBean方向，能加入新的類和屬性。

到了測試/發佈的環節，代碼能夠從代碼庫中下載打包，到達測試/最終用戶的手裏。數據庫表結構的變更，如何到達測試/正式環境？

其中的一個解決辦法，就是將數據庫設計文件也打包到軟件發佈包中，發佈新版軟件時，用數據庫設計工具把最新設計文件，體現到新環境的數據庫中。可是發佈新版本還要拽着先進的數據庫設計工具，不多有公司這麼作。

Hibernate支持這種方案的變種，咱們能夠從數據庫設計文件生成 hbm文件（咱們把hbm文件當作數據庫設計文件的另外一種表現），它隨着新代碼一同發佈到新的環境中，在啓動時，Hibernate就會依據hbm文件把數據庫的變動應用到新的數據庫環境中。

非Hibernate體系如何作？遙想當年EJB2.0時代，每次變動完數據庫設計文件（固然，咱們項目組人多的時候，每每都不變動數據庫設計文件，直接在數據庫裏面改了），要手工把數據庫變更的DDL語句轉存成sql腳本文件（入代碼庫）。「入代碼庫」四個字打上括號，是由於項目組人數多的時候，總有人忘記上傳本身的腳本。等到整體發佈測試環境的時候，手忙腳亂，A少入庫了sql腳本，B搞錯了sql腳本的執行順序。等到交付用戶的時候，又會發現，當初緊急修改的內容，數據庫結構是改了，數據庫設計文件沒有改。

縱觀上面的過程，其實咱們發現要維護：設計文件、代碼、數據庫三者的同步。若是咱們以設計文件爲核心，那麼，設計文件和開發環境的代碼同步還好處理，在發佈階段，設計文件和測試/生產環境的數據庫結構就難同步了:一則除了powerdesigner（廣告）外，咱們確實沒有特別好的工具作這種同步，二則使用手工腳本的辦法太容易出錯了，三則不是全部的項目都用Hibernate。

       若是，設計階段，咱們維護設計文件，開發階段，由設計文件和代碼同步，在發佈階段，再由代碼和數據庫結構同步，就擺脫了設計文件直接同步到測試/生產數據庫這種尷尬的狀況了。讓咱們的JavaBean中，存儲上數據庫的信息，是否是會好一點？

 

@Table (name = "st_user") public class User {       /** 帳號 */     @Column (length = 64, nullable = false, unique = true)     private String account;       /** 密碼 */     @Column (length = 64)     private String password; }

 

假設上面這個JavaBean是咱們用數據庫設計工具，從數據庫設計文件生成的,它帶了一些數據庫層面的信息（table_name,column_length等），那麼正好能夠在系統啓動階段，驗證正在使用的數據庫是否和設計匹配，若是不匹配，咱們也能夠作對錶結構作一些更改，使之符合設計要求。

       咱們發佈的時候，既不用發佈設計文件，也就沒必要帶着那些ddl了，咱們的bean早就洞悉了一切。