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