|
作者：Flyingis 許多軟件設(shè)計的思維都源于生活的方方面面，可能存在某些設(shè)計思想并非受平時生活所啟迪，但它們面臨的情況卻如此相象。軟件設(shè)計原本就是生活的一部分，軟件設(shè)計的“靈活”與“方便”(或“簡便”)即是世界萬物的一個共同點。 Hibernate作為流行的企業(yè)應(yīng)用和關(guān)系數(shù)據(jù)庫之間的持久化中間件，受到越來越多的關(guān)注。雖然使用Hibernate可以使得項目易于維護(hù)，幫助開發(fā)人員更好地處理復(fù)雜關(guān)系模型，提供了很強(qiáng)的方便性，但卻失去了JDBC原有的靈活性。如何在“靈活”與“方便”之間取舍、平衡顯得重要起來。 不久前江南白衣的一篇文章ORM透明持久化方案面對的共同困境道出了現(xiàn)在ORM不盡如人意的地方，除了網(wǎng)上，還有書本的前言等對Hibernate的眾多贊美之詞外，現(xiàn)在討論它呆板、配置繁瑣的聲音也逐漸多了起來，最熱鬧的就是前段時間Ruby on Rails引起J2EE陣營的騷動。個人對Java研究尚淺，對Hibernate有一些使用心得，下面所列出的不一定是Hibernate本身的缺陷，不足之處希望大家拍磚指出。 1. 提取表單中字典Value的不便。 字典一般由ID和NAME兩個字段組成，其ID號存儲于數(shù)據(jù)庫其他表中，當(dāng)查詢這些表信息時，Hibernate以List或Set形式返回的結(jié)果，沒有辦法將ID號顯示為對應(yīng)的NAME。在JDBC中，可以直接通過Map來存儲字典，通過map.getValue()來返回字典的值。 2. Hibernate內(nèi)置映射類型復(fù)雜化 在開發(fā)過程中，時常會查找Hibernate映射類型--Java類型--標(biāo)準(zhǔn)SQL類型之間的關(guān)系。繁雜之處體現(xiàn)在兩方面，一是各種數(shù)據(jù)庫的數(shù)據(jù)類型和標(biāo)準(zhǔn)SQL之間會有一定的出入，二是Hibernate映射類型雖然大部分和Java類型相同，但也存在比較晦澀的地方，例如character類型對應(yīng)Java的char / java.lang.Character / java.lang.String，text對應(yīng)著Java的java.lang.String。 3. ID規(guī)定化生成 Hibernate中內(nèi)置標(biāo)識符生成器給表單ID自動生成提供了方便，但卻不能自定義各種ID形式。開發(fā)過程中，有時需要特定的ID號來區(qū)分各種字典，例如字典1的ID號為1A，2A……，字典2的ID號為1B，2B……，當(dāng)這些ID號存儲在表單中時，可以方便開發(fā)人員在數(shù)據(jù)庫中查找各表單存儲各類字典數(shù)據(jù)的情況，方便調(diào)試，但使用Hibernate生成器就失去了這種靈活性。 Hibernate的不足網(wǎng)上已有很多討論，以上只是個人增加的幾點體會。即使這樣，Hibernate仍是一款優(yōu)秀的持久層插件，只是“靈活”的背后隱藏著“復(fù)雜”，“方便”的背后隱藏著“不便”，如何取舍與平衡，還是看實際需要吧。 |
|
|
