現在我正在製作一個非常簡單的網站 - 大約5頁。問題在於它是否過度殺傷,值得花時間整合某種數據庫映射解決方案,或者如果使用普通的舊式JNDI會更好。我可能會需要從數據庫讀取/寫入數十個東西。我想我對這些技術有一個基本的瞭解,但它仍然需要大量的參考文檔。其他人以前面臨過這個決定嗎?何時使用Hibernate/JPA/Toplink?
編輯:對不起,我應該指定JNDI來查找數據庫連接和JDBC來執行操作。
現在我正在製作一個非常簡單的網站 - 大約5頁。問題在於它是否過度殺傷,值得花時間整合某種數據庫映射解決方案,或者如果使用普通的舊式JNDI會更好。我可能會需要從數據庫讀取/寫入數十個東西。我想我對這些技術有一個基本的瞭解,但它仍然需要大量的參考文檔。其他人以前面臨過這個決定嗎?何時使用Hibernate/JPA/Toplink?
編輯:對不起,我應該指定JNDI來查找數據庫連接和JDBC來執行操作。
簡答:這取決於你想要支持的複雜性。
龍答:
首先,ORM( - 當你把它叫做數據庫映射 - 對象關係映射)和JNDI(Java命名和目錄接口)是兩個不同的東西。
第一個你已經知道的,用於將數據庫表映射到類和對象。第二個是爲資源提供查找機制,它們可能是DataSources,Ejb,Queues或其他。
也許你的意思是「JDBC」。
現在至於你的問題:如果是這樣簡單的話可能不需要實現一個ORM。我想,這個數字表格最多隻有5到10個,而且操作非常簡單。
可能使用普通的JDBC就足夠了。
如果您使用DAO模式,您可能稍後將其更改爲在需要時支持ORM策略。
像這樣: 假設你有一個Employee表
你用手工所有數據庫的字段(它不應該太長),並用類似方法EmployeeDaO.java創建Employee.java:
+findById(id): Employee
+insert(Employee)
+update(Employee)
+delete(Employee)
+findAll():List<Employee>
和實現是相當直截了當:
select * from employee where id = ?
insert into employee (bla, bla, bla) values (? , ? , ?)
update etc. etc
當(如果)你的應用程序變得過於複雜,你米改變DAO的實現。例如,在「select」方法中,您將代碼更改爲使用執行該操作的ORM對象。
public Employee selectById(int id) {
// Commenting out the previous implementation...
// String query = select * from employee where id = ?
// execute(query)
// Using the ORM solution
Session session = getSession();
Employee e = (Employee) session.get(Employee.clas, id);
return e;
}
這僅僅是一個例子,在現實生活中,你可以讓abstact工廠創建ORM DAO,但是這是offtopic。關鍵是你可以開始簡單,通過使用設計模式,如果需要,你可以稍後改變實現。
當然,如果你想學習這項技術,你甚至可以用一張表開始。
選擇一種或另一種(ORM解決方案)基本上取決於您使用的技術。例如對於JBoss或其他開源產品來說,Hibernate非常棒。它是開源的,有很多資源可以從中學習。但是如果你使用的東西已經有了Toplink(比如oracle應用服務器),或者如果基礎已經建立在Toplink上,你應該使用該框架。
順便說一句,由於甲骨文收購了BEA,他們表示他們正在用名爲「Oracle Weblogic Application Server」的頂級鏈接取代Kodo(weblogic peresistence framework)。
我離開你一些資源,在那裏你可以得到更多這方面的信息:
這是Hibernate的入門教程:
的Toplink的官方頁面:
最後我 「認爲」 很好的思考JPA的是,你可能最近更改供應商。
開始簡單然後進化。
我希望這會有所幫助。
看起來這對於一個非常簡單的應用程序來說太過於誇張了,特別是如果你沒有計劃擴展它的話。但是,似乎也可以將這些簡單的應用程序用到這些應用程序中,這樣您就可以更好地瞭解它們在下次有什麼東西可以使用時的工作方式。
你的意思是普通的JDBC嗎? 一個小型項目可能是挑選其中一個ORM框架的好機會,尤其是如果你有時間的話。
沒有更多的信息,很難提供一種方式或另一種建議。
我的經驗法則是,如果它是隻讀的,我願意在JDBC中完成它,但我更喜歡使用帶有SQLQuery的空Hibernate項目來利用Hibernate的類型映射。一旦我必須寫入數據,我就會使用Hibernate,因爲設置幾個屬性然後調用save比單獨設置每個列要容易得多。而當你必須開始優化以避免更新未更改的對象時,用OR/M和它的骯髒檢查你會更好。處理外鍵關係是另一個跡象,你需要映射一次然後使用getters。同樣的邏輯也適用於Toplink,儘管自從我使用它之後的3年中,除非他們添加了像HQL這樣的東西,否則Hibernate對於從純SQL中進行這種轉換會更好。請記住,您不必映射每個對象/表,只有那些有明顯優勢的對象/表。根據我的經驗,大多數不使用現有OR/M的項目最終會構建一個新的項目,這是一個壞主意。
該最好學習方式ORM是一個小項目。從這個項目開始。
一旦你掌握了它,你會使用ORM的一切。
ORM沒有太小的東西。在你的第一對項目之後,你會發現你不能以其他方式工作。 ORM映射通常比其他任何工作方式更有意義。
看看這裏的各種排名靠前的導遊,他們介紹,示例場景等