Struts2 ile projemi Google App Engine üzerinde geliştirmek istiyorum. Veritabanı için JPA ve JDO olmak üzere iki seçeneğim var. Lütfen bana bunu önerir misiniz? İkisi de benim için yeni ve onları öğrenmem gerekiyor. Bu yüzden cevaplarınızdan sonra bir tanesine odaklanacağım.
Teşekkürler.
Yanıtlar:
JPA, Sun'ın kalıcılık standardıdır, JDO, IMHO ölüyor (aslında, ölü ama hala hareket ediyor). Diğer bir deyişle, JPA uzun vadede daha iyi bir yatırım gibi görünüyor. Bu yüzden, eğer ikisi de benim için yeniyse, JPA seçerdim.
GAE / J google grubunun tam da bu konuyla ilgili birkaç yayını var. Orada bir araştırma yapıp insanların fikirlerine bakardım. Yukarıda ifade edilen görüşlerden çok farklı bir mesaj alacaksınız. Ayrıca BigTable'ın bir RDBMS olmadığı gerçeğine odaklanın. İş için doğru aracı kullanın
DataNucleus tarafından JPA ve JDO arasındaki bu karşılaştırmayı az önce gördüm: - http://www.datanucleus.org/products/accessplatform_2_1/jdo_jpa_faq.html Bir göz açıcı.
JDO'nun mutlu bir kullanıcısıyım. İyi işlere devam edin çocuklar.
JDO'nun öldüğünü iddia eden insanlar haksız değildir. İşte Pro EJB 3 Java Persistence API kitabında okuduğum şey: "Kısa bir süre sonra Sun, JDO'nun teknik özellik bakım moduna indirileceğini ve Java Persistence API'nin hem JDO'dan hem de diğer kalıcı satıcılardan yararlanacağını ve desteklenen tek satıcı olacağını duyurdu. standart ileriye gidiyor. " Yazar Mike Keith, EJB3'ün ortak spesifikasyon lideridir. Tabii ki JPA'nın büyük bir destekçisi ama yalan söyleyecek kadar önyargılı olduğundan şüpheliyim.
Kitap yayınlandığında, JDO'nun JPA'dan daha gelişmiş teknik özelliklere sahip olmasına rağmen, çoğu büyük satıcının JDO yerine JPA arkasında birleştiği doğrudur. Şaşırtıcı değil çünkü EE dünyasındaki IBM / Oracle gibi büyük oyuncular da büyük RDBMS satıcıları. Daha fazla müşteri, projelerinde RDMBS olmayanlara göre RDMBS kullanıyor. GAE büyük bir destek sağlayana kadar JDO ölüyordu. GAE veri deposu ilişkisel veritabanı olmadığı için mantıklıdır. Bazı JPA özellikleri, toplama sorguları, Birleştirme sorguları, sahip olunan çoktan çoğa ilişkiler gibi büyük tablolarla çalışmaz. BTW, GAE, JDO 2.3'ü desteklerken yalnızca JPA 1.0'ı destekler. GAE hedef bulut platformunuzsa, JDO'yu önereceğim.
Kayıt için, Google App Engine (GAE), bu yüzden Oracle / Sun kurallarına göre değil Google kurallarına göre oynuyoruz.
Bunun altında JPA, GAE için uygun değildir, kararsızdır ve beklendiği gibi çalışmaz. Ne Google onu desteklemeye istekli değil, asgari düzeyde.
Diğer taraftan JDO, GAE'de oldukça kararlıdır ve (bir ölçüde) Google tarafından iyi bir şekilde belgelenmiştir.
Ancak Google bunların hiçbirini önermemektedir.
http://code.google.com/appengine/docs/java/datastore/overview.html
Düşük seviyeli API en iyi performansı verir ve GAE tamamen performansla ilgilidir.
Örneğin, 10 varlık ekleyin
Python: 68 ms
JDO: 378 ms
Java Yerel: 30 ms
JDO ile JPA arasındaki yarışta sadece datanucleus posterlerine katılıyorum.
Her şeyden önce ve en önemlisi, datanucleus posterleri ne yaptıklarını biliyor. Sonuçta kalıcı bir kitaplık geliştiriyorlar ve ilişkisel dışındaki veri modellerine aşinalar, örneğin Büyük Masa. Eminim ki hazırda bekletme için bir geliştiricinin burada olduğunu söylerdi: "Çekirdek kitaplıklarımızı oluştururken tüm varsayımlarımız ilişkisel modele sıkı sıkıya bağlıdır, hazırda bekletme GAE için optimize edilmemiştir".
İkincisi, JPA tartışmasız olarak daha yaygın kullanımdadır, resmi Java EE yığınının bir parçası olmak biraz yardımcı olur, ancak bu daha iyi olduğu anlamına gelmez. Aslında, JDO, onu okursanız, JPA'dan daha yüksek bir soyutlama seviyesine karşılık gelir. JPA, RDBMS veri modeline sıkı sıkıya bağlıdır.
Programlama açısından bakıldığında, JDO API'lerini kullanmak çok daha iyi bir seçenektir çünkü kavramsal olarak çok daha az ödün veriyorsunuz. Kullandığınız sağlayıcının temel veritabanını desteklemesi koşuluyla, teorik olarak arzu ettiğiniz herhangi bir veri modeline geçebilirsiniz. (Uygulamada nadiren bu kadar yüksek düzeyde şeffaflık elde edersiniz, çünkü kendinizi GAE'nin nesnesine birincil anahtarlarınızı ayarlarken bulacaksınız ve kendinizi belirli bir veritabanı sağlayıcısına, örneğin google'a bağlayacaksınız). yine de taşınması daha kolay olacaktır.
Üçüncüsü, Hazırda Bekletme, Eclipse Bağlantısı ve hatta GAE ile bahar kullanabilirsiniz. Google, uygulamalarınızı oluştururken kullandığınız çerçeveleri kullanmanıza izin vermek için büyük bir çaba sarf etmiş görünüyor. Ancak insanların GAE uygulamalarını RDBMS üzerinde çalışıyormuş gibi oluşturduklarında fark ettikleri şey, yavaş olmalarıdır. GAE'de bahar YAVAŞ. Bunun doğru olduğunu görmek için bu konudaki Google IO videolarını google'da arayabilirsiniz.
Ayrıca, standartlara bağlı kalmak mantıklı bir şeydir, prensip olarak alkışlarım. Öte yandan, JPA'nın Java EE yığınının bir parçası olması, insanların zaman zaman seçenek kavramlarını kaybetmelerine neden olur. Java Sunucusu Yüzlerinin de Java EE yığınının bir parçası olduğunu anlayın. Ve web GUI geliştirme için inanılmaz derecede düzenli bir çözümdür. Ama sonunda, neden insanlar, daha zeki insanlar söylersem, bu standarttan sapıp onun yerine GWT'yi kullanıyorlar?
Tüm bunlarda, JPA için çok önemli bir şeyin gittiğini söylemeliyim. Bu Guice ve JPA için uygun desteği. Görünüşe göre google bu noktada her zamanki kadar akıllı değil ve şimdilik JDO'yu desteklememekten memnun. Hala karşılayabileceklerini düşünüyorum ve sonunda Guice JDO'yu da yutacak, ... ya da belki alamayacak.
Bunu JDOyazarken kullanmanın korkunç olduğunu düşündüğüm şey , tek uygulama sağlayıcısının olması Datanucleusve bunun dezavantajları, aşağıdakiler gibi sayısız soruna yol açan rekabet eksikliğidir:
extensionsStackOverflowHer zaman birisinin JDOspesifikasyonu kendi başına uygulamaya başlamasını umuyorum , belki o zaman topluluğa daha fazla ve umarım daha özgür bir ilgi sunacaklar ve destek için ödeme alma konusunda her zaman endişelenmeyecekler, Datanucleusyazarların yalnızca ticari desteği önemsediğini söylemeyeceğim. ama ben sadece söylüyorum.
Ben şahsen Datanucleusyazarların Datanucleuskendisine veya topluluğuna karşı hiçbir yükümlülüğü olmadığını düşünüyorum. Tüm projeyi istedikleri zaman bırakabilirler ve hiç kimse onları bunun için yargılayamaz, bu onların çabası ve kendi mallarıdır. Ama neye bulaştığını bilmelisin. Görüyorsunuz, geliştiricilerden biri kullanmak için bir çerçeve aradığında, çerçevenin yazarını cezalandıramaz veya ona komuta edemezsiniz, ancak diğer yandan, işinizin tamamlanması gerekir! Bu çerçeveyi yazmaya zamanınız olsaydı, neden ilk başta bir tane ararsınız?
Öte yandan, JDOnesnelerin yaşam döngüsü ve çok sezgisel ve yaygın olmayan şeyler gibi bazı komplikasyonları var (sanırım).
Düzenleme: Artık JPAnesne yaşam döngüsü mekanizmasını da zorladığını biliyorum , bu nedenle standart bir ORM API (yani JPAveya JDO) kullanmak istiyorsanız kalıcı varlıkların yaşam döngüsü durumlarıyla başa çıkmanın kaçınılmaz gibi görünüyor
En sevdiğim şey JDO, HERHANGİ bir veritabanı yönetim sistemiyle kayda değer bir çaba harcamadan çalışabilme becerisidir.
GAE / J, yıl sonundan önce MYSQL ekleyecektir.
JPA, standartlaştırılmış bir API olarak zorlandığı ve son zamanlarda EJB3.0'da ivme kazandığı için gitmenin yoludur. JDO, buharı kaybetmiş görünüyor.
Hiçbiri!
Daha ucuz (daha az kaynak kullanın) ve daha hızlı olduğu için Objectify kullanın. Bilginize: http://paulonjava.blogspot.mx/2010/12/tuning-google-appengine.html
Objectify, Google App Engine veri deposu için özel olarak tasarlanmış bir Java veri erişim API'sidir. Bir "orta zemin" kaplar; kullanımı daha kolay ve JDO veya JPA'dan daha şeffaf, ancak Düşük Seviye API'den önemli ölçüde daha kullanışlıdır. Objectify, acemileri anında üretken hale getirmek ve aynı zamanda GAE veri deposunun tüm gücünü ortaya çıkarmak için tasarlanmıştır.
Objectify, kendi yazdığınız nesneleri kalıcı hale getirmenize, almanıza, silmenize ve sorgulamanıza olanak tanır.
@Entity
class Car {
@Id String vin; // Can be Long, long, or String
String color;
}
ofy().save().entity(new Car("123123", "red")).now();
Car c = ofy().load().type(Car.class).id("123123").now();
ofy().delete().entity(c);