Bir gün herkes repository pattern kullanmayacak
Satranç tahtasında, her bir taşın basit bir hareketi vardır, ancak bu basit hareketler bir araya geldiğinde sonsuz sayıda karmaşık strateji ortaya çıkar. Yazılım dünyası da benzer bir şekilde işler. Kod satırları, tıpkı satranç taşları gibi, basit yapı taşlarıdır. Ancak bu basit yapılar, bir araya geldiklerinde devasa ve karmaşık sistemler oluşturur. Bu sistemleri tasarlarken, tıpkı satranç oyuncuları gibi, farklı stratejiler ve taktikler kullanırız. Design Pattern’lar, yazılım mimarisindeki bu stratejilerin en bilinenlerindendir. Ancak, her strateji her oyuna uygun olmadığı gibi, her tasarım deseni de her projeye uymayabilir. Bugün, yazılım dünyasının popüler hamlelerinden biri olan Repository Pattern’i mercek altına alacağız.
Repository Pattern, bir arama motoru aramasıyla kolaylıkla yüzlerce bilgi bulabileceğimiz bir tasarım deseni, design pattern. Amaç, veriye olan erişim katmanını business tarafından ayırmak, bağımsız olmasını sağlamak ve veriye erişen kısmın tek noktada toplanmasıdır. Bu patterni kullanmanın bize sayısız avantaj kazandıracağı çok açık. Maddeler halinde sıralamak gerekirse;
- Data Source Bağımsızlığı:
Olur da bir gün veritabanımızı değiştirmek istersek, komple uygulamamızı değiştirmek yerine sadece repository katmanını güncellememiz yeterli olacaktır. - Kod Tekrarı:
Veriye erişim için kullanılan kodlar tekrar kullanılabildiği için kod tekrarı azalır. - Test Edilebilirlik:
Kolayca mocklanan objeler, kim itiraz edebilir ki? - Data Source Tek Bir Kütüphanede:
Veriye erişim tek noktada olacağı için, kaynak sistemde oluşabilecek aykırı durumların sorun tespitindeki yerini bulmak çok daha kolay olacaktır.
Tüm bunlar değerlendirildiğinde bir projede repository pattern kullanılması çok mantıklı gözüküyor. Zira geçen senelerde bir çok yazılımcı, mimar arkadaşımız bu tatlı avantajları düşünüp, gözü kapalı bir şekilde her projede ilgili entitylerini oluşturduktan sonra repositorylerini yazmaya başlıyor. Yok yok, ne repositorysi, daha da iyisi Generic Repository yazılıyor. Ne kadar az kod, o kadar iyi ne de olsa. Maalesef, yazılım geliştirme aşamalarında, sorgulanmayan, önümüze dayatılan, hypelanan bir çok konudan sadece bir tanesi bu. Tabii ki bu patternleri bulan, kitaplaştıran, kullanımımıza sunan insanları eleştirmek değil amacım. 2002 yılında, repository patternine ‘Patterns of Enterprise Application Architecture’ kitabında yer veren Martin Fowler’ı eleştirmek benim haddime değil, ancak bu patterni ne zaman kullanılması gerektiğini söylemeden sürekli bloglarda, kitaplarda hypelayanlara birkaç sözümüz olsun elbet :)
Magazin tarafını geçip gerçeklere dönme vakti. Öncelikle şunu belirteyim, repository pattern uygulamak için gerekli olan en önemli motivasyon olan veritabanı değişikliği halinde işinizin kolaylaşacağı düşünülmesi. Bu maalesef çok geçerli bir argüman değil. Bu durum gerçekleşmesi çok düşük bir ihtimal ki gerçekleşti diyelim. Bu durumda sizin zorlanacağınız yer, hangi kodun dbyi çağırdığı ile alakalı olmayacak. Oracle’dan Postgres’e geçtiğinizde sizi zorlayacak olan yer çok daha farklı, Oracledaki data tipleri, functionlar, prosedürler… Birinin diğerinin karşılığı nedir, bunlarla ciddi zaman harcayacaksınız. Buna ilave olarak veritabanına olan erişimi tek bir katmanda ya da kütüphanede toplamak için repository pattern şart değil. Bunun için basit query objeleri hazırlayabilirsiniz. Aynı şekilde bu query objeleriyle repository patterninin diğer avantajlarını da yakalıyorsunuz. Proje canlı yayında senelerce aynı data source ile çalışacaksa neden birden fazla interface’e ihtiyaç duyalım? Biz birden fazla farklı data kaynağıyla hibrit bir şekilde dağıtık olarak veritabanı kullanıyoruz diyorsanız o zaman zaten interfaceiniz olmak zorunda :) Bu bahsettiğim senaryo, oracle ve postgres’in aynı anda aktif olduğu ve eş zamanlı data senkronizasyonunun çalıştığı senaryodur. Böyle bir senaryo oldukça nadirdir.
Repository Pattern ne zaman kullanabilirizin ikinci doğru cevabı ise, sizin ürününüzü paylaşmanızdır. Eğer ürününüz bir paket program gibi veya on-premise olarak kullandırıyorsanız bu durumda ürünü kullanan ya da satın alan kişi kendi alışık olduğu teknolojilere göre ürününüzü özelleştirebilir, bu yönde kullanabilir. A müşterisi DB olarak PostgreSQL üzerinde uzmanlaşmıştır ve postgres kullanmayı tercih edebiliyorken, B müşterisi Microsoft SQL, Oracle, MariaDB, MySql tercih edebilir. Bu durumda repository pattern size gerçekten faydalı olabilir.
İlave olarak bugün bir çok ORM, repository katmanının yaptığı abstractionu halihazırda yapıyor. Bunun ile ilgili detayları yazmak isterdim ama Ayende Rahien’in blog yazısının tercümesi gibi olacak ve hiçbir zaman onun anlattığı gibi anlatabilecek yetkinlikte olduğumu düşünmüyorum. İlgili yazıyı buradan okuyabilirsiniz.