şükela:  tümü | bugün
  • j2ee 5 ve ejb 3 ile java dünyamıza resmi olarak giren uygulama geçiştirme arayüzü**
    temel olarak persistent objeleri* ile veritabanı arasındaki ilişkinin direktoman persistence class üzerinde map edilmesidir**
    hibernate gibi frameworklerde obje-veritabanı ilişkisi xml dosyasında tanımlanırken bu direk class üzerinde tanımlanabilir hale gelmiş,"çok süper olmuş" diyerek önümüze sürülmüştür.alıntı yaparak örnek vermek gerekirse

    <table-generator name="emp_gen"
    table="generator_table"
    pk-column-name="key"
    value-column-name="hi"
    pk-column-value="emp"
    allocation-size="20"/>

    şeklinde xml'e entity tanımlamak yerine

    @javax.persistence.tablegenerator(
    name="emp_gen",
    table="generator_table",
    pkcolumnname = "key",
    valuecolumnname = "hi"
    pkcolumnvalue="emp",
    allocationsize=20
    )

    formatında class tanımının başına yazılmaktadır.aradaki fak benim gibi dünyanın en yüzelsey adamını kendini idol olarak benimsemişler için,birisinde reverse engineering kullanarak var olan db'den xml mappingler çıkarmak,diğerinde bunları direk classlara yazmaktan ibarettir.

    kullanım kolaylığına gelirsek,xml oluşturmak için reverse engineering ile db ye bağlanım xmli otomatik oluşturan toollar kullanılırken (bu toollar da xdoclet kullanmaktadır), diğerinde xdoclet hardcore kullanılmaktadır.en azından şimdilik annotationlari otomatik tanimlayan bir tool ortalıkta yok*
    ayrıca (bkz: hibernate annotations)
  • (bkz: mr persister)
  • veritabanından bağımsız kodlama yapabilmenizi ve sorgular hazırlayabilmenizi olanaklı kılar. java geliştiricilerine veritabanı tabloları ile sınıflar arasında mapping imkanı sunarak, ilişkisel veritabanlarının nesne tabanlı bir geliştirme iskeleti ile kolaylıkla yönetilmesini sağlar. the java persistence api, java persistence query language ve nesne/tablo ilişkisini gösteren mapping metadataları gibi üç kola ayrılmış bir geliştirim mantığı vardır. jpql (java persistence query language) ile yazacağınız sorgular, veritabanınızdaki ilişkisel yapıya göre hazırladığınız, birbiriyle ilişkili pojo nesnelerini kullandığınız sorgular olacaktır (örneğin jpa'ya, bana bu sınıfın şu id'li kaydını getir dersiniz ve şak diye nesneyi önünüze koyar). jpa'nın size sunduğu imkanlar ile çoğu basit işlemi (kayıt silme, ekleme ve birleştirme) de, jpql kullanmadan, kolaylıkla halledebilme olanağına sahipsinizdir.
  • select new classismi(...) şeklinde bir sorgusu var bunun. sırf bunun için bile native sql'den hemen şimdi, şu anda, derhal vazgeçebilirim. hatta vazgeçtim. kral.
  • database operasyonları dışındaki işlerinize odaklanmanıza olanak tanıyan bir java türevi framework. (bkz: hibernate) sayesinde sizlere en iyi performansı da sunmaktadır.
  • bir türlü anlayamadığım ilişki yapısı sayesinde projenin ortasında vazgeçmek zorunda kaldığım java türevi framework.
  • eclipselink'i tercih ediyor ve bir iki ufak numarasını biliyorsanız zaman içerisinde
    pratik ve hızlı olarak kullanabileğiniz framework. jdbc'ye alışkın olan baba coder'ların
    ilk başlarda burun kıvırdıkları ama genellikle ısındıkları yapı.

    reverse db model güzel. table-to-entity (veya tam tersi) güzel çalışıyor ama oracle'da
    tam bir baş derdi. özellikle ilk kez sequence'ler ile ilgili bir kod yazıyorsanız sizi olduğunuz
    yerde sıçtırtabiliyor. alıştıktan sonra problem yok.

    ama tam bir info model değil. eğer, business logic'in kullandığı ayrı bir info model varsa
    entity'ler ile serialize etmeniz gerekebiliyor ki pek verimli değil zaman açısından. yine de
    daha pratik bir yolu vardır, diye düşünmekteyim.

    ben mi?

    yok, ben yazılımcı değilim. bizim çocuklar kasıyordu. onlardan duyduklarımı size
    satıyorum. yoksa bir bok anladığımdan değil...
  • modüler ve type-safe sorgulama olsun diye aşırı kasmış api, olabildiğince basit haliyle kullanılması tavsiye edilir.
  • kompleks sorgular gerekmedikçe, veri tabanından uygulama katmanına doğru düzgün tek satır kod yazmadan veri getirmeye yarayabilen şeytan işi api.
  • 2.1 versiyonu 2013 yılında yayınlanmıştır. çerçevesi jsr 338 kodlu spesifikasyon ile çizilmiş, referans implementasyonu eclipselink dir.

    kabaca veri erişim katmanı için bir soyutlama oluşturur. jpql, criteria api gibi yapılar sayesinde karmaşık sorgular da dahil olmak üzere pek çok veritabanı operasyonu gerçekleştirebilecek yapıdadır.

    eclipselink'in yanı sıra, yaygın olarak bilinen hibernate, open jpa ve yerli implementasyon olarak batoo mevcuttur. hasan ceylan'ın yaşamını yitirmesinden sonra batoo devam ediyormu emin değilim. ancak performans açısından oldukça iddialıydı.

    performas açısından bir değerlendirme yapacak olursak; kullanılacak veritabanına göre her implementasyon farklı performanslar sergilemektedir. örneğin, postgresql + eclipselink, postgresql + hibernate'den çok daha iyi sonuçlar verirken, mysql + hibernate, mysql + eclipselink'den az da olsa daha iyi sonuçlar vermektedir.

    detaylı benchmark için şuraya bakılabilir. bir çok karşılaştırma var.

    java tarafında genelde referans implementasyonları seçme gibi bir eğilimim olduğundan eclipselink bana daha yakın geliyor.