Repository Pattern, veri erişim sorgularını uygulamanın iş kurallarından ayırmak için kullanılan bir tasarım yaklaşımıdır. Her PHP projesinde zorunlu değildir: yalnızca aynı sorgular farklı yerlerde tekrarlandığında veya veri kaynağı değişiminin maliyeti belirgin olduğunda ek soyutlama yararlı olur.
Sorumluluk sınırı
Controller HTTP isteğini çözer, servis iş kuralını yürütür, repository kayıt okuma ve yazma işlemlerini kapsar. Repository içine e-posta gönderimi, fiyat hesaplama veya yetki kararı taşınırsa sınır bulanıklaşır.
Örneğin OrderRepository::findById ve save yöntemleri siparişin kalıcılığını yönetebilir. “Sipariş iadesi yapılabilir mi?” sorusu servis veya alan modelinin kuralıdır.
PHP projesinde uygulama sırası
Önce gerçek sorgu ihtiyacını belirleyin. Arayüze yalnızca kullanılan yöntemleri ekleyin; her veritabanı tablosu için otomatik genel CRUD sınıfı üretmeyin. PDO veya ORM uygulamasını bu arayüzün arkasına koyun ve servise yapıcı üzerinden verin.
Birim testinde yalnızca iş kuralını ayırmak için sahte repository kullanabilirsiniz. Sorgunun SQL davranışı, transaction sınırı ve performansı için gerçek veritabanıyla entegrasyon testi de gereklidir.
Ne zaman kullanmamalı?
Küçük, tek sorgulu bir uygulamada ORM üzerine aynı yöntemleri yeniden yazmak bakım yükü ekleyebilir. Önce tekrarı, test zorluğunu ve alan mantığının veri erişimine ne kadar bağlandığını ölçün. N+1 sorgu, sayfalama ve transaction sorunlarını repository adı tek başına çözmez.
Kaynaklar ve İleri Okuma
