Repository Pattern (Ambar Deseni) Nedir?
Repository (Ambar) deseni iş mantığınızı veri kaynağınızdan soyutlamanın bir yoludur. Veri getirme kodunuzun üstünde ekstra bir katman olup değişik yollarla kullanılabilmektedir.
Bu Deseni Neden Kullanırız?
Bir ambarın amacı kodun sürdürülebilirliğini artırmak ve kodunuzu uygulamanızın kullandığı durumlar çerçevesinde oluşturmaktır.
Birçok geliştirici bunu sadece daha büyük ölçekli uygulamalar için gerekli bir araç olarak düşünür, ancak ben çoğu uygulama için kullanıyorum. Artıları ekstra kod yazma, eksilerine ağır basmaktadır.
Yararlarından bir kısmının üzerinden geçelim:
Bağımlılık Inversiyonu
Bu SOLID ilkelerinin bir ifadesidir. Ambar deseni bize verilerimizi işlemesini amaçladığımız bir interface’in uygun birçok implementasyonunu oluşturmamıza imkan verir.
En çok bahsedilen kullanma durumu “veri kaynağınızı değiştirmektir”. Bu, uygulama kodunuzu etkilemeksizin bir veri deposundan bir başkasına, örneğin MySQL’den NoSQL veritabanına geçiş yapılabilmesini tarif etmektedir.
Bu, verinizi elde etmek için bir interface oluşturarak gerçekleştirilir. Daha sonra bu interface için bir veya birçok implementasyon oluşturabilirsiniz.
Örneğin, bizim article repository çerçevesindeki mantık için, Eloquent kullanan bir implementasyon oluşturacağız. Veri kaynağımızı MongoDB’ye değiştirme gereği duyarsak, bir MongoDB implementasyonu oluşturup ona geçebiliriz. Uygulama kodumuz somut bir sınıf yerine bir interface beklediği için, bir interface’in bir implementasyonundan bir başkasına geçtiğimizde bu farkı bilmeyecektir.
Eğer veri deponuzu uygulamanızın birçok yerinde kullanıyorsanız (büyük ihtimalle böyledir), bu çok güçlü bir etkide olacaktır. Büyük bir ihtimalle, ister bir controllerde ister bir komutla ister bir kuyruk işi olarak ister form işleme kodunuzda yapılsın, uygulamanıza yapılan hemen her çağrıda verinizle etkileşiyorsunuz.
Uygulamanızın her bir alanının gerekli metodlara daima sahip olacağından emin olabilirseniz, geleceğe giden yolda ilerlemeniz çok daha kolay olacaktır.
Fakat gerçekte, veri kaynağınızı ne sıklıkta değiştirirsiniz? Çekirdek SQL-tabanlı veri kaynağınızı nadiren değiştirirsiniz. Bununla birlikte, repository deseni kullanmanın başka bazı sebepleri de vardır.
Planlama
Daha önce uygulama kodlamasına bakış açımın iş mantığı etrafında toplandığını söylemiştim. Bir interface oluşturulması, kodunuzun iş gerekleriniz (kullanım durumları) etrafında planlanmasında çok yararlıdır.
Her implementasyonun kullanacağı metodları tanımladığınız zaman, domain’inizin kullanım durumlarını planlıyorsunuz. Kullanıcılar makale oluşturabilecekler mi? Yoksa makaleleri sadece okuyabilecekler mi? Sıradan bir kullanıcıya göre yöneticilerle ne gibi farklı etkileşimlerde bulunulacak?
Interface’lerin tanımlanması size uygulamanızın bir veri perspektifi yerine nasıl bir domain perspektifi kullanacağı konusunda daha net bir görüntü verecektir.
İş Mantığı Oryantasyonu
İş domain’i etrafında planlama fikrine dayalı bir inşa, iş domain’inizi gerçekten kodunuzda ifade etmek demektir. Her bir Eloquent modelinin tek bir veritabanı tablosunu temsil ettiğini hatırlayınız. Sizin iş mantığınız böyle değildir.
Örneğin, örnek uygulamamızdaki bir article articles tablomuzdaki bir satırdan daha fazlasıdır. O aynı zamanda users tablosundan bir author’ı, statuses tablosundan bir status’u ve tags ve articles_tags tablolarında temsil edilen bir tag’lar kümesini de içermektedir. Bir article bileşik bir iş antitesidir; sadece kendi title, content ve yayınlanma tarihi gibi niteliklerinden başka, diğer antiteleri de içeren bir iş antitesidir.
Repository deseni bize bir makaleyi bir tablodaki tek bir satırdan daha fazlası olarak ifade etmemizi sağlar. Ham verinin bizim iş antitemizin gerçek temsilcilerine çevrilmesi için ne gerekiyorsa, bunun için Eloquent modellerimizi, ilişkilerini ve sorgu oluşturucusunu kombine edebilir veya bir arada kullanabiliriz.
Veri Katmanı Mantığı
Veri repository, veri getirmeyle ilgili diğer mantığınızı eklemek için çok uygun bir yerdir. Ekstra mantığı Eloquent modellerimize eklemek yerine, bunları barındırmak için repository’mizi kullanabiliriz.
Örneğin, verilerinizi cache’lemeniz gerekebilir. Data repository’miz cache’leme katmanınızı eklemek için de harika bir yerdir.
Uzak Veri
Verilerinizin birçok kaynaktan -sizin veritabanınız olması şart değil- gelebileceğini akılda tutmak önemlidir.
Birçok modern web uygulaması mash-up'tır. Bunlar birçok API kullanırlar ve son kullanıcıya yararlı veri sunarlar. Bir data repository, API bilgilerinin elde edilmesi ve uygulamanızın kolaylıkla kullanabileceği veya işleyeceği bir antiteye kombine edilmesi mantığının barındırılması için de bir yol olabilir.
Ayrıca bir Service Oriented Architecture (SOA, Servis Yönelimli Mimari)’de de yararlıdır. Bu mimaride kendi alt yapımız içindeki servis(ler)e API çağrıları yapmamız gerekebilir ama bir veritabanına doğrudan erişemeyiz.
