Hangi Java ORM'yi tercih edersiniz ve neden? [kapalı]

Bu oldukça açık uçlu bir soru. Yeni bir proje başlatacağım ve veritabanı erişimi ile entegre etmek için farklı ORM'lere bakacağım.

Hiç favoriniz var mı? Temiz kalmanızı tavsiye edecek biriniz var mı?

ORM'leri kullanmayı bıraktım.

Nedeni, konseptte büyük bir kusur değildir. Hazırda bekletme iyi çalışıyor. Bunun yerine, sorguların düşük yükü olduğunu buldum ve büyük SQL sorgularına çok sayıda karmaşık mantık sığdırabilir ve işlemimin çoğunu veritabanına kaydırabilirim.

Bu yüzden sadece JDBC paketini kullanmayı düşünün.

Hiçbiri, çünkü bir ORM'ye sahip olmak, küçük faydalarla çok fazla kontrolü elinden alır. ORM kullanımından kaynaklanan anormalliklerin hatalarını ayıklamanız gerektiğinde, kazanılan zaman tasarrufu kolayca ortadan kaldırılır. Dahası, ORM'ler geliştiricileri SQL öğrenmesini ve ilişkisel veritabanlarının nasıl çalıştığını ve bunu kendi yararları için kullanmasını önler.

Birçok ORM harika, neden JDBC'nin üstüne soyutlama eklemek istediğinizi bilmelisiniz. Size http ://www.jooq.org'u tavsiye edebilirim (feragatname: jOOQ'nun yaratıcısıyım, bu yüzden bu cevap önyargılı). JOOQ aşağıdaki paradigmayı benimser:

• SQL iyi bir şeydir. SQL'de birçok şey oldukça güzel ifade edilebilir. SQL'in tam olarak soyutlanmasına gerek yoktur.
• İlişkisel veri modeli iyi bir şeydir. Son 40 yıldır en iyi veri modelini kanıtladı. XML veritabanlarına veya gerçekte nesne yönelimli veri modellerine gerek yoktur. Bunun yerine, şirketiniz Oracle, MySQL, MSSQL, DB2 veya başka herhangi bir RDBMS örneğini çalıştırır.
• SQL bir yapıya ve sözdizimine sahiptir. Her ikisi de sözdizimi hatalarına sahip olmaya eğilimli olan JDBC'de "düşük düzeyli" Dize birleştirme veya HQL'de "yüksek düzeyli" Dize birleştirme kullanılarak ifade edilmemelidir.
• Değişken bağlama, büyük sorgularla uğraşırken çok karmaşık olma eğilimindedir. Bu soyutlanması gereken bir şey.
• POJO'lar, veritabanı verilerini işleyen Java kodu yazarken mükemmeldir.
• POJO'lar elle yazmak ve korumak için bir acıdır. Kod üretmenin yolu budur. Veri türü güvenliği de dahil olmak üzere derleme güvenli sorgularınız olacaktır.
• Veritabanı önce gelir. Veritabanınızın üstündeki uygulama zamanla değişse de, veritabanının kendisi muhtemelen daha uzun sürecektir.
• Evet, eski veritabanınızda saklı yordamlar ve kullanıcı tanımlı türler (UDT'ler) var. Veritabanı aracınız bunu desteklemelidir.

Daha birçok iyi ORM var. Özellikle Hibernate veya iBATIS'in harika bir topluluğu var. Ancak sezgisel, basit bir tane arıyorsanız, jOOQ'yu deneyin. Çok seveceksiniz! :-)

Bu örnek SQL'e göz atın:

  // Select authors with books that are sold out
  SELECT * 
    FROM T_AUTHOR a
   WHERE EXISTS (SELECT 1
                   FROM T_BOOK
                  WHERE T_BOOK.STATUS = 'SOLD OUT'
                    AND T_BOOK.AUTHOR_ID = a.ID);

Ve nasıl JOOQ ile ifade edilebilir:

  // Alias the author table
  TAuthor a = T_AUTHOR.as("a");

  // Use the aliased table in the select statement
  create.selectFrom(a)
        .whereExists(create.selectOne()
                           .from(T_BOOK)
                           .where(T_BOOK.STATUS.equal(TBookStatus.SOLD_OUT)
                           .and(T_BOOK.AUTHOR_ID.equal(a.ID))))));

Hazırda bekletme, çünkü temelde Java'daki defacto standardı ve JPA'nın oluşturulmasında itici güçlerden biriydi. İlkbaharda mükemmel bir desteğe sahip ve neredeyse her Java çerçevesi bunu destekliyor. Son olarak, GORM, Groovy kullanarak dinamik bulucular vb.

Hatta orada da kullanabilmeniz için .NET'e (NHibernate) taşınmıştır.

Hazırda bekletme, çünkü:

• istikrarlı - uzun yıllar boyunca etrafta olmak, büyük sorunlardan yoksundur
• ORM alanındaki standartları belirler
• dikte etmenin yanı sıra standardı (JPA) uygular.
• İnternette tonlarca bilgi var. Birçok öğretici, yaygın sorun çözümü vb. Vardır.
• güçlüdür - çok karmaşık bir nesne modelini ilişkisel bir modele çevirebilirsiniz.
• herhangi bir büyük ve orta RDBMS desteği vardır
• iyi öğrendikten sonra çalışmak kolaydır

ORM'yi neden (ve ne zaman) kullanacağınıza dair birkaç nokta:

• sisteminizdeki nesnelerle çalışırsınız (sisteminiz iyi tasarlanmışsa). JDBC kullanıyor olsanız bile, verilerinizi nesnelerinize aktarmanız için bir çeviri katmanı oluşturacaksınız. Ancak bahislerim, hazırda bekletmenin çeviri sırasında herhangi bir özel çözümden daha iyi olduğudur.
• sizi kontrolünüzden mahrum bırakmaz. İşleri çok küçük ayrıntılarla kontrol edebilirsiniz ve API'nin uzak bir özelliği yoksa - yerel bir sorgu yürütün ve bunu elde edin.
• herhangi bir orta büyüklükte veya daha büyük sistem, sürdürülebilir olması amaçlanıyorsa, bir ton sorguya (tek bir yerde veya dağılmış olsun) sahip olmayı göze alamaz
• performans kritik değilse. Hazırda Bekletme, bazı durumlarda göz ardı edilemeyecek performans ek yükü ekler.

MyBatis kullanmanızı tavsiye ederim . JDBC'nin üstünde ince bir katmandır, nesneleri tablolara eşlemek ve hala düz SQL kullanmak çok kolaydır, her şey kontrolünüz altındadır.

Orta ölçekli bir JavaSE uygulaması yazarken Avaje Ebean ile gerçekten iyi bir deneyim yaşadım.

Varlıkları tanımlamak için standart JPA ek açıklamaları kullanır, ancak çok daha basit bir API (No EntityManager veya bu bağlı / ayrılmış varlıklardan herhangi biri) gösterir. Ayrıca gerektiğinde SQL sorgularını veya olay düz JDBC çağrılarını kolayca kullanmanızı sağlar.

Ayrıca sorgular için çok güzel bir akışkan ve tip-güvenli API'ye sahiptir. Şöyle şeyler yazabilirsiniz:

List<Person> boys = Ebean.find(Person.class)
                                  .where()
                                       .eq("gender", "M")
                                       .le("age", 18)
                                  .orderBy("firstName")
                                  .findList();

SimpleORM , çünkü düz ileri ve sihirsiz . Java kodundaki tüm meta veri yapılarını tanımlar ve çok esnektir.

SimpleORM, ilişkisel bir veritabanındaki verileri bellekteki Java nesnelerine eşleyerek Hazırda Bekletme işlevine benzer işlevler sağlar. Java nesneleri açısından sorgular belirtilebilir, nesne kimliği veritabanı anahtarları ile hizalanır, nesneler arasındaki ilişkiler korunur ve değiştirilen nesneler iyimser kilitlerle veritabanına otomatik olarak temizlenir.

Ancak Hazırda Beklet'in aksine, SimpleORM karmaşık ayrıştırma, bayt kodu işleme vb. Gereksinimlerini ortadan kaldıran çok basit bir nesne yapısı ve mimarisi kullanır. bağımlılık (Slf4j). (Hazırda Bekletme 2400K'nın üzerinde ve yaklaşık 2000K bağımlı Kavanozun üzerindedir.) Bu, SimpleORM'un anlaşılmasını kolaylaştırır ve teknik riski büyük ölçüde azaltır.

Eclipse Link , birçok nedenden dolayı, ama özellikle diğer ana akış çözümlerinden (en azından yüzünüzde şişkinlik) daha az şişkinliğe sahip olduğunu hissediyorum.

Oh ve Eclipse Link JPA 2.0 için referans uygulama olarak seçildi

Serbest biçimli SQL sorguları için Java değiştirmeleriyle ilgili endişeleri paylaşırken, ORM'yi eleştiren insanların genellikle kötü bir uygulama tasarımı nedeniyle bunu yaptığını düşünüyorum.

Gerçek OOD sınıflar ve ilişkiler tarafından yönlendirilir ve ORM size farklı ilişki türleri ve nesnelerin tutarlı eşlemesini sağlar. Bir ORM aracı kullanır ve ORM çerçevesinin desteklediği sorgu dilinde (Java ifade ağaçları, sorgu yöntemleri, OQL vb. Dahil ancak bunlarla sınırlı olmamak üzere) sorgu ifadelerini kodlarsanız, kesinlikle yanlış bir şey yapıyorsunuz, yani sınıf modeliniz büyük olasılıkla ihtiyaçlarınızı olması gerektiği gibi desteklemez. Temiz bir uygulama tasarımının uygulama düzeyinde sorgulara ihtiyacı yoktur. İnsanların bir ORM çerçevesini SQL kod sabitlerini kodlarına gömmek için kullanıldıkları gibi kullanmaya başladıkları birçok projeyi yeniden düzenledim ve sonunda herkes eşleştirildikten sonra tüm uygulamanın ne kadar basit ve bakımı kolay olacağı konusunda şaşırdı sınıf modelinizi kullanım modeliyle geliştirin. Verilmiş, arama işlevselliği gibi şeyler için bir sorgu diline ihtiyacınız var, ancak o zaman bile sorgular o kadar kısıtlı ki, daha da karmaşık bir VIEW oluşturup, salt okunur kalıcı bir sınıfa eşlemek, ifadeleri oluşturmaktan daha güzel ve bakımı daha güzel. uygulamanızın kodundaki bazı sorgu dillerinde. VIEW yaklaşımı ayrıca veritabanı yeteneklerinden de yararlanır ve materyalizasyon yoluyla Java kaynağınızdaki elle yazılmış herhangi bir SQL'den çok daha iyi performans açısından daha iyi olabilir. Bu nedenle, önemsiz olmayan bir uygulamanın ORM kullanmaması için herhangi bir neden göremiyorum. ancak o zaman bile sorgular o kadar kısıtlıdır ki, daha da karmaşık bir VIEW oluşturmak ve salt okunur kalıcı bir sınıfa eşlemek, uygulamanızın kodunda bazı sorgu dillerinde ifadeler oluşturmaktan çok daha güzeldir. VIEW yaklaşımı ayrıca veritabanı yeteneklerinden de yararlanır ve materyalizasyon yoluyla Java kaynağınızdaki elle yazılmış herhangi bir SQL'den çok daha iyi performans açısından daha iyi olabilir. Bu nedenle, önemsiz olmayan bir uygulamanın ORM kullanmaması için herhangi bir neden göremiyorum. ancak o zaman bile, sorgular o kadar kısıtlıdır ki, daha da karmaşık bir VIEW oluşturmak ve salt okunur kalıcı bir sınıfa eşlemek, uygulamanızın kodunda bazı sorgu dillerinde ifadeler oluşturmaktan çok daha güzeldir. VIEW yaklaşımı ayrıca veritabanı yeteneklerinden de yararlanır ve materyalizasyon yoluyla Java kaynağınızdaki elle yazılmış herhangi bir SQL'den çok daha iyi performans açısından daha iyi olabilir. Bu nedenle, önemsiz olmayan bir uygulamanın ORM kullanmaması için herhangi bir neden göremiyorum.