JDBC Programlama için 5 Öneri

Java ile veritabanı erişimi için JDBC kullanmayı daha önce anlatmıştım. Bu anlatım yeni başlayanlar için bazı basit ve temel bilgileri içeriyordu. JDBC'yi artık sıklıkla kullandığınızı düşünelim, ve bir günlük yazısında karşılaştığım önemli önerileri paylaşalım:

1. Bağlantıları kapatın: Ne olursa olsun, hata ile karşılaşsanız bile sql bağlantılarını kapatın, kapatmayı unutmayın. Bu pratiği unuttuğunuzda programınızın hiç beklemediğiniz sorunlarla karşılaştığını görebilirsiniz. Elbette bu pratik yerine kullanılabilecek başka bir çözüm de bağlantı havuzu kullanımıdır. Böylece izin verilen bağlantı sayısını ve bunların kontrolünü sağlayabilirsiniz.

Kod Örneği:

Connection con;
try {
  con = …
} finally {
  try { if(con!=null) {con.close();}}
  catch (Exception e1) {}
}

2. Standart "Statement" yerine "PreparedStatement" kullanın: PreparedStatement kullanımı size bir çok avantaj sağlayacaktır (sağlıklı sorgular, düzenli girdi/çıktı şeklinde sorgular, başarım artışı). Bu yüzden sağlıklı bir şekilde PreparedStatement kullanmak gereklidir:

Örnek:
Statement statement = con.createStatement();
statement.executeQuery(“SELECT name FROM widgets WHERE type = ‘WidgetB’”);

Yerine:
final String widgetType = “WidgetB”;
Statement pStatement = con.prepareStatement(“SELECT name FROM widgets WHERE type = ?”);
pStatement.setString(1,widgetType);
pStatement.executeQuery();

3. Veritabanı platformu değişimlerine hazırlıklı olmak: Her zaman kullanıcıların isteği veya kendi kararınızla veritabanı değiştirebilirsiniz. Buna her zaman hazırlıklı olmanız gerekir. Yarın öbür gün MySQL kullandığınız bir program için PostgreSQL kullanmaya karar verebilirsiniz (Bkz: En sondaki yorumum)

4. Hiç bir zaman veritabanı sistemine özgü kütüphanedeki sınıfları kullanmayın: OracleCallableStatement cst = (OracleCallableStatement)conn.prepareCall şeklinde bir kullanım yaptığınızda bilin ki eğer Oracle'dan vazgeçmek zorunda kalırsanız kodu da aynı şekilde değiştirmeniz gerekecektir. Bu yüzden sadece JDBC tarafından sağlanan ve Java ile her zaman dağıtılan genel sınıfları kullanın.

5. Veritabanı stored procedure'leri kullanmayın: Yaşadığım özel sektör deneyimlerinden ve kişisel projelerimden yola çıkarak söyleyebilirim ki, en nefret ettiğim şey stored procedure kullanımıdır. Sizi veritabanı sistemine mahkum eder, değiştirmek zordur uzmanlık ister. Projenize özgü ve Java ile yapabileceğiniz hiç bir şeyi stored procedure ile yapmayın.

6. JSP içerisinde JDBC kodu kullanmayın: Bu herkesin bilmesi gereken bir şeydir. Dinamik web dosyalarınızın içerisine (PHP olsun, JDBC olsun) veritabanı sorgularını koymamak gerekir. Bunun için soyutlama yaparak başka sınıfları sorumlu tutup, işleri o sınıfta yapmanız makbul olan yoldur (Araştırınız: MVC, Üç katmanlı mimari, vb.).

Ek yorumum: Yukarıdaki zorluklardan bir kısmından kurtulmak istiyorsanız kalıcı katman kullanmaya çalışmalısınız. Başlangıç için

8 yorum:

Racih dedi ki...

6 önemli maddeyi açıkladığınız için çok teşekkür ederim hocam :).

Benim 5. maddede kafam karıştı. C# kursunda hocamız stored procedure kesinlikle kullanımı yoğun olan sistemlerde kullanın derdi. Böylelikle daha hızlı olacağını söyledi. Yani sizin dediğiniz yoğun olmayan sistemlerdemi kullanılmamalı ?

Ek notunuzda dediğiniz kalıcı katman, her projede kullanabileceğim bir class mı ?

Bu yazınız için tekrar teşekkür ederim :)

İyi günler ...

Tahir Emre Kalaycı dedi ki...

Yorum ve sorular için teşekkürler.

Soruları sondan cevaplamaya çalışayım.

Kalıcı katmanlar, veritabanı bağımsızlığını sağlayan, işlemlerini kolaylaştıran, nesne yönelimli yazılım geliştirmeye ve üç katmanlı mimarinin iyi bir şekilde uygulanmasına katkı sağlayan kütüphanelerdir, frameworklerdir. Kalıcı katman kullanarak veri katmanını, görünüm katmanından kolaylıkla ayırmış olursunuz ve ilgisi olmayan yerlere sql kodu, sql işlemleri koymamış olursunuz. Hangi projelerde kullanabileceğinize gelince, genellikle CRUD (Create-Read-Update-Delete Çoğu proje bu şekildedir) projelerinde işleri oldukça kolaylaştırmaktadır. Elbette kullanacağınız katman frameworkunun (Örnekler: Hibernate, Java Persistence API, ...) yaratacağı iş yükü ve ekleyeceği karmaşıklık yaptığınız projeninkinden oldukça fazla ise siz projeden ziyade kalıcı katman ve ayarlarıyla uğraşmak zorunda kalırsınız. Bunu tavsiye etmiyorum (Her ne kadar veritabanı kullanan her projede kalıcı katman kullanmaya çalışma gibi bir pratiği benimsemiş olsam da - bu pratik proje gelişmelerine ve veritabanı bağımsızlığına oldukça katkı sağlıyor).

Gelelim stored procedure konusuna. Bu sürekli tartışılan ve belki de bir karara varılamayan bir konudur. Kişilerin bireysel tecrübeleri, sıklıkla kullandıkları yazılım geliştirme metodolojisi ve kullandıkları platformlar, aldıkları eğitim bu konudaki görüşlerini oluşturuyor.

Düşünerek gidecek olursak, stored procedure yazdığınız zaman ilgili veritabanı yöneticisine genellikle tamamen bağımlı hale gelmiş oluyorsunuz, ve stored procedureler sizin projenizin içerisinde olmayan tamamen farklı yapılar haline geliyor. Ayrıca yazdığınız stored procedurleri hatırlamanız, güncellerken sıkıntı yaşamamanız kolay şeyler değildir. Sisteminiz sürekli değişen ve gelişen bir şey olduğuna ve olacağına göre kendinizi stored procedure gibi değiştirilmesi zor olan şeylere mahkum etmemeniz gerekir. Nesne yönelimli yazılım geliştirirken özellikle stored procedure kullanımından kaçınmanız gerekir. Bu yöntem (SP kullanımı) genellikle veritabanı yönelimli yazılım geliştirme kültüründen gelen insanların önerisi oluyor. Bütün işleri zaten hızlı olan SP'lere yaptıralım biz sadece onları değiştirelim diyorlar. Ancak benim önerim, mümkün olduğunda SP kullanımından kaçınmaktır. Başınızı mutlaka ağrıtacaktır.Bazı durumlarda ise (bağlantıda önerildiği gibi) SP kullanmanız anlamlıdır ancak bunları da sizin projenizden bağımsız tasarlamanız ve kullanmanız gerekecektir. Sizin projenizi SP'lere bağımlı hale getirmemek için.(Bağlantıdaki yorumları okursanız orada da gerçek anlamda çok miktarda batch işlem gerekmedikçe SP kullanmayın deniyor, özellikle iş mantığı dediğimiz kısımı kesinlikle SP ile yapmamak lazım. Çünkü projelerin karmaşıklığını arttırır, değiştirilmesi zordur, bilen kişi kalmayınca sabit bir şekilde kalır)

C# hocanıza ayrıca sormak lazım "Neden" diye? Büyük ihtimalle .NET platformu ve dolayısıyla SQL Server anlatıyordu ve başka bir veritabanı kullanımı, nesne yönelimli yazılım geliştirme, projelerin değişebilirliği, vb. konularda bir açıklama getirmesi zor olacaktır. Onun bunu söylemedeki amacı "hız"dan başka bir şey olmayacaktır diye düşünüyorum.

Benim önerim, yine tekrarlıyorum, SP'lerden mümkün olduğunca kaçınmak. Mümkünse kullanmamak. Sistemin büyüklüğünün bir önemi yok. Dikkat ederseniz ben sürekli projelerde veritabanı sistemine özgü şeylerden kaçınmayı öneriyorum.

İyi çalışmalar

Racih dedi ki...

Merhaba hocam ilk önce Bayramınız mübarek olsun diyim. :)

Hibernate ve java persistence api sinin tam bu noktada kullanıldığını bilmiyordum :) . Ben veritabanına bağlanmayla alakalı bir class oluşturuyordum. Birde sql sorguları için bir class oluşturuyordum.İlkel olarak iş yaptığımın farkında değildim. Şimdi öğrenmiş oldum :) Sağolun.

Bir sorum daha olacak. Ben şuan küçük bir uygulama geliştiriyorum. Bu program sadece, kendi dbsinde olan linux dağıtımlardan birisini seçerek indiriyor. Ben bu projenin ilerki sürümünde EJB ye geçirsem uygun olur mu ?

Stored procedure konusunda hocamız veri tabanı ile uygulama arasındaki iletişimi anlatıyordu. Ve her şey ms ürünü olduğu için db ye bağlanma sorgu oluşturmalar 2 dk lık bir iş. O yüzden kafayı hıza takıyordu. Spleri kullanalım derken yazılımın geliştirme esnekliğide azalacaktır demi hocam.

Cevabınız için teşekkür ederim. Benim java hakkında ileriye gitmem için bir klavuz oldu.

İyi günler ...

Tahir Emre Kalaycı dedi ki...

Uygulama küçük olduğu için bu noktada kalıcı katman kullanımını tavsiye edemeyeceğim açıkçası :) Sadece üç katmanlı, bilemediniz iki katmanlı bir mimariye uygun olarak veritabanı ve görünüm (grafiksel arayüz) kısımlarını birbirinden iyi bir şekilde ayırmak da işe yarayabilir.

Nesne yönelimli yaklaşımda amacımız projeyi yönetilebilir ve değişimlerde birbirini etkileyemecek parçalara bölmektir mümkün olduğunca. Bunu Model-Görünüm-Denetleyici (Model-View-Controller) tasarım deseni yaklaşımını kullanarak kolaylaştırabiliriz (bu tasarım deseni genellikle web projelerinde kullanılıyor).

http://www.csharpnedir.com/makalegoster.asp?MId=769

http://sozluk.sourtimes.org/show.asp?t=model+view+controller

Racih dedi ki...

Doğru, ben 3 katmanlı mimaride kalayım :).

İlginizi teşekkürler ... :)

Kaan Arslan dedi ki...

Sizin stored procedure kullanmayın derken kastettiğiniz şey yanlış gibi. Söylemek istediğiniz, business logic işlemleri gibi şeyleri stored procedure üzerinden yapmayın demekti sanırım. Bence toptan sp kullanmayın demek yanlış, daha çok işlemleri olabildiğince java tarafında gerçekleştirin demek gerekir. Yoksa ben sadece sql sorgularım için stored procedure kullanmak istersem sorun olmaz.

Tahir Emre Kalaycı dedi ki...

Benim bahsettiğim gerekçeler doğrultusunda stored procedure kullanmanız sorun yaratmıyorsa kullanabilirsiniz, ama zaten SP kullanmayın derken yarattığı sorunlardan dolayı diyorum.

SP'yi sadece sorgularım için kullanırım derken neyi kastettiğiniz önemli aslında. Benim attığım ilk yorumda SP kullanmama tabirini açmaya çalıştım. Bazı durumlarda kullanılabileceğini ben de kabul ediyorum, ki bu durumlar genellikle batch işlemler, raporlama işlemleri oluyor. Bu durumda bile yazılımın veritabanını değiştirmek istediğinizde bu SP'leri taşımanız ve belki de yeniden yazmanız gerekecektir. Elbette veritabanını değiştirmemek te bir çözümdür. Ben genel olarak deneyimlerim ve gördüklerim doğrultusunda SP kullanımından kaçınmayı öneriyorum.

Kaan Arslan dedi ki...

Sadece sorgular derken, ansi sql sorgularından bahsediyorum. Yani veritabanı üzerinde direkt işlem yapmaktan değil (Örneğin, cursor açıp bunun üzerinde işlem yapmak gibi). Bu tarz sorguları spler üzerinde tutmak, onların tek bir yerden erişimini sağlıyor ve yönetimini kolaylaştırıyor.

Evet bende zaten işlemlerin olabildiğince kod tarafında yapılmasından yanayım, sizinde dediğiniz gibi hem veritabanı bağımlılığı hemde hız açısından çoğu zaman önemli.