Java Persistence Api (JPA ile programlama) -1

Merhaba arkadaslar  ;

Oncelikle  nesne-ilişkisel uymsuzluğunu ele alıp hızlıca tarihi olarak bu uyumsuzluğu gidermek için ortaya çıkan çözümlerden bahsedeceğiz cunku bu uyumsuzluk yuzunden JPA ortaya cikmistir. Bu yuzden ilk once kod yazmaktansa edebi kismina biraz kafa yoralim hersey kolaylasacaktir .

J2EE ‘de bir uygulama gelistirdigimizde sınıflar/nesneler ile aralarındaki ilişkilerin ifade ediliş şekli,  iliskisel veritabanindaki tablolar ve aralarındaki ilişkilerin ifade edilişinden pek çok bakımdan farklılık arzeder. Bu iki sistem, kapsülleme (encapsulation), tip, erişim, güvenlik vb. pek çok temel konuda, değişik çıkış noktalarına sahip olmalarından dolayı, farklı yaklaşımlar benimsemişlerdir. Bu durum nesne-ilişkisel uyumsuzluğu (object-relational mismatch) olarak adlandırılır.Nesnelerin tablolarda kalıcı hale getirilmeleri için uygulamadaki sınıfların veri tabanındaki tablolara, sınıflarda tanımlanan nesne özelliklerinin yani nesne değişkenlerinin (instance/object variables) de bu tablolardaki sütunlarla/kolonlarla eşleştirilmesi gerekmektedir. Buna da “nesne-ilişkisel eşleştirme”  (Object-Relational Mapping, ORM) denir.

Nesne-merkezli diller ile geliştirilen uygulamalarda nesne-ilişkisel uyumsuzluğunu tekrar tekrar yaşayan programcıların bu problemi aşmak için geliştirdikleri çözüm iliskisel veritabanini ile uygulama arasına konulacak böyle bir katmanın iki arayüzü olacaktır: Birisi SQL’ı kullanarak iliskisel veritabani  ile haberleşen arayüz, diğeri ise bir API üzerinden nesnelerle alakalı business methods işlemlerini ( reate, read, update, delete ) yapmaya izin veren arayüz. Dolayısıyla bu katman, uygulama programcılarını, arkadaki veritabaninin ilişikisel yapısından uzak tutacak ve onlara, nesneleri sanki OODBMS ( object-oriented database management system) kalıcı kılıyormuş gibi program yazma imkanı sağlayacaktır.

Hibernate ,TopLink vs  yukarda anlattigimiz gibi katmanlar  , API’lere sahiptiler   ama  bundan dolayida problemler ortaya cikti  hepsinin farklı bir yaklaşıma dolayısıyla da bir API’ye sahip olmalarıydı. Bu yüzden bu çözümler birbirlerinin yerine geçebilir durumda değillerdi. Bu süreçte Sun, bu problemine bir başka çözüm önermek üzere yola çıktı ve eski tecrübeleri ile Toplink ve Hibernate gibi başarılı araçların birikimlerini bir araya getirerek JPA (Java Persistence API) isimli yeni bir bileşen yayınladı. Ana teması “daha kolay geliştirme” olan Java EE 5’in içindeki EJB 3.0’ın bir parçası olarak 2006 yılında Javacılara sunulan JPA 1.0, büyük bir ilgiyle karşılalandı.

JPA nin dogusunu anladiktan sonra Entity nedir buna bakalim .Entity’i şu blogda (Akin Kaldiroglu) güzel bir şekilde anlatmış oradan alıntı yapalım.

Entity

JPA’yı kullanarak veri tabanında kalıcı kılınacak olan nesneye entity denir. Bir nesnenin entity olması için gerek ve yeter şart o nesnenin kendisinden üretileceği sınıfın @Entity  olarak ifade edilmesidir.  Entity bir iç sınıf (inner class), bir interface ya da enum tipi veya final olmamalıdır ve public ya da protected olan bir argumansız yapılandırıcısı (no-arg constructor) olmalıdır.

Entitynin veri tabanında saklanancak olan kalıcı durumu (persistent state), tamamen nesne değişkenlerinden oluşacaktır. Bu yüzden kalıcı durumun parçası olacak nesne değişkenleri final olmamalıdır. Nesne değişkenleri private olabilir hatta olmalıdır ve kalıcı olan nesnenin istemcileri (client), nesnenin değişkenlerine get/set metotları ile ulaşmalıdır. Entitylerin kalıcılığının minimum sayıda alandan (nesne değişkeni) oluşması gerektiği düşünüldüğünde, veri tabanında kalıcı olması gerekmeyen değişkenler @Transient ile notlandırılmasının gerekir.

Bir sınıfın entity olması için teorik olarak zorunlu olmamakla birlikte konulmadığında pratikte pek çok sıkıntı çıkardığı için gerekli olarak belirttiğimiz bir diğer not ise @Id’dir. Bu not, notlandırdığı alanın, içinde bulunduğu nesnenin kimlik (identity) bilgisini ifade etmesini ve veri tabanında da bir anahtar alana (primary key) karşı gelmesini sağlamaktadır.

Yukarıdaki bilgiler ışığında aşağıdaki gibi bir sınıf JPA tarafından veri tabanında kalıcı hale getirilecektir:

 

yukarda gordugunuz gbi biz normal java sinifi olusturduk ama iliskisel veritabanimiza bir tablo yaratmis gibi olduk tablo ismi verdik kolon isimleri  vs hepsini atadik . Bunlari yukarida anlattigim gibi katman veya API olusturmak zorunda kalmadik isimizi birkac annotation yazarak hallettik.

 

JPA, bir JPA ürünü ve kullanılacak veri tabanıyla ilgili olarak yapılacak ayarları classpathde META-INF klasörünün altında persistence.xml isimli bir dosyada olmasını bekler. Biz de projemizde böyle bir dosya oluşturup içine Hibernate ve kullanacağımız veri tabanıyla alakalı en temel bilgileri aşağıdaki gibi verebiliriz:

 

 

Tanımladığımız bu kalıcılık biriminin işlem (transaction) tipi ise “RESOURCE_LOCAL” olarak verilmiş durumda. “RESOURCE_LOCAL” işlem tipi, JPA’in işlemleri herhangi bir JTA altyapısı kullanmadan yöneteceğini ifade eder. Bu tipin alternatifi “JTA”dir ve bu durumda JPA kullanabileceği bir JTA ürünü arar ki en temelde böyle bir durum, bir uygulama sunucusunun varlığı halinde kullanılır. Biz bu yazımızda JPA’in sadece Java SE ortamında nasıl kullanıldığınından bahsedeceğimiz için işlem tipimiz daima “RESOURCE_LOCAL” olacaktır.

Artik tablolarimiz olusturulduguna gore entity manager ile kucuk testler yapalim zaten tum database islemlerini onun sayesinde yapacagiz (create , update ,delete vs)

EntityManager

 

simdi arkadaslar su yazdigimiz iki satira dikkat;

KiliclarJPU1 isminde name yazmisiz simdi yukari cikarak persistence.xml dosyanisin persistence-unit name ile ayni olmasi lazimdir cunku database hangisi oldugunu anlamaz ve exception firlatir..

SELECT f FROM Firma f bu syntax’da kullanilmasinda ki amac f degiskeni atamislar oraya mesela f.firs_name seklinde daha esnek bir yapida bilgiyi cekebiliyoruz JPQL de basli basina bir konu insallah onumuzdeki yazimda ona deginecek saglicakla kalin ..

Umarim faydali olmustur
😉

About Mehmet KILIÇ

Bilgisayar Mühendisi