Bölüm 7 — Konu 32: Repository Pattern, Katmanlı Mimari (Data/Domain/Presentation)

#Sorun: Her Şey Karışık Olunca Ne Olur?

Bölüm 5'te öğrendiğimiz HTTP istekleri, JSON serialization ve yerel depolamayı hatırlarsan — eğer bir widget'ın build() metodu içinde, doğrudan http.get(...) çağırıp, jsonDecode yapıp, Hive'a kaydediyorsan, bu kod hızla karmaşıklaşır ve test edilmesi, değiştirilmesi zorlaşır. Bu ders, bu karmaşıklığı düzenli katmanlara ayırmayı öğretiyor.

#Katmanlı Mimari — Üç Temel Katman

Presentation (Sunum) → Domain (İş Mantığı) → Data (Veri)
     Widget'lar         İş kuralları          API/DB erişimi

Her katmanın tek bir sorumluluğu vardır — bu, Bölüm 3 Konu 13'te öğrendiğimiz "tek sorumluluk" prensibinin, tüm uygulama mimarisine uygulanmış hali.

#Data Katmanı — Ham Veriye Erişim

// data/urun_veri_kaynagi.dart
class UrunVeriKaynagi {
  final http.Client _client;
  UrunVeriKaynagi(this._client);

  Future<List<Map<String, dynamic>>> urunleriGetir() async {
    final response = await _client.get(Uri.parse('https://api.ornek.com/urunler'));
    return List<Map<String, dynamic>>.from(jsonDecode(response.body));
  }
}

Bu katman, Bölüm 5 Konu 20'de öğrendiğimiz http paketi kullanımını doğrudan barındırır — sadece "veriyi nereden alıyoruz" sorusuyla ilgilenir, hiçbir iş mantığı içermez.

#Repository — Data Katmanının "Soyutlanmış Arayüzü"

// domain/urun_repository.dart
abstract class UrunRepository { // Dart Bölüm 7 Konu 34'ü hatırla — soyut sınıf!
  Future<List<Urun>> urunleriGetir();
}

// data/urun_repository_impl.dart
class UrunRepositoryImpl implements UrunRepository { // Dart Bölüm 7 Konu 35'i hatırla — implements!
  final UrunVeriKaynagi _veriKaynagi;
  UrunRepositoryImpl(this._veriKaynagi);

  @override
  Future<List<Urun>> urunleriGetir() async {
    final hamVeri = await _veriKaynagi.urunleriGetir();
    return hamVeri.map((json) => Urun.fromJson(json)).toList(); // Bölüm 5 Konu 21'i hatırla!
  }
}

Bu, Dart Bölüm 7'de öğrendiğimiz abstract class + implements kavramının en klasik gerçek dünya kullanımıdır! UrunRepository, bir "sözleşme" tanımlıyor ("bir yerden ürün listesi getirebilmeliyim"), UrunRepositoryImpl ise bunu HTTP API'den getirerek implemente ediyor.

Neden bu ayrım değerli? Dart Bölüm 8'de (Flutter müfredatı, test yazımı konusunda) göreceğimiz gibi, UrunRepository soyut olduğu için, testlerde sahte (mock/fake) bir implementasyon kullanabilirsin — gerçek bir API çağrısı yapmadan, UrunRepository'nin sözleşmesine uyan herhangi bir sahte class'ı test amaçlı kullanabilirsin. Bu, Bölüm 7 Konu 35'te (Dart) öğrendiğimiz "implements, sadece sözleşmeyi devralır" prensibinin, test edilebilirlik açısından pratik değerini gösteriyor.

#Domain Katmanı — İş Mantığı (Use Case'ler)

// domain/indirimli_urunleri_getir_usecase.dart
class IndirimliUrunleriGetirUseCase {
  final UrunRepository _repository;
  IndirimliUrunleriGetirUseCase(this._repository);

  Future<List<Urun>> call() async {
    final tumUrunler = await _repository.urunleriGetir();
    return tumUrunler.where((urun) => urun.indirimdeMi).toList(); // Dart Bölüm 11'i hatırla!
  }
}

"Use Case" (kullanım senaryosu), tek bir iş mantığı işlemini temsil eden bir class'tır — burada "indirimli ürünleri getir" gibi. Dart Bölüm 11'de öğrendiğimiz .where() metodu, burada iş mantığının (hangi ürünler "indirimli" sayılır) repository'den (veri erişiminden) ayrı tutulduğunu gösteriyor — repository, "tüm ürünleri getir" diyor; use case, "bunlardan hangileri indirimli" kararını veriyor.

#Presentation Katmanı — Widget'lar + State Management

// presentation/urun_listesi_ekrani.dart
class UrunListesiEkrani extends ConsumerWidget { // Bölüm 6 Konu 25'i hatırla — Riverpod!
  const UrunListesiEkrani({super.key});

  @override
  Widget build(BuildContext context, WidgetRef ref) {
    final urunlerAsync = ref.watch(indirimliUrunlerProvider);

    return Scaffold(
      appBar: AppBar(title: Text('İndirimli Ürünler')),
      body: urunlerAsync.when(
        data: (urunler) => ListView.builder(
          itemCount: urunler.length,
          itemBuilder: (context, index) => ListTile(title: Text(urunler[index].ad)),
        ),
        loading: () => CircularProgressIndicator(),
        error: (err, stack) => Text('Hata: $err'),
      ),
    );
  }
}

Bu katman, sadece görüntüleme ile ilgilenir — Bölüm 3'te öğrendiğimiz ListView.builder, Bölüm 6'da öğrendiğimiz Riverpod entegrasyonu burada bir araya geliyor, ama hiçbir HTTP çağrısı veya iş mantığı içermiyor — bunlar alt katmanlara devredilmiş durumda.

#Neden Bu Kadar Katman? — Somut Faydalar

1. Test edilebilirlik: Her katman bağımsız olarak test edilebilir. Use case'i test etmek için, gerçek bir API'ye ihtiyacın yok — sahte bir UrunRepository (Dart Bölüm 7'de öğrendiğimiz implements ile) yeterli.

2. Değişime dayanıklılık: Yarın, veri kaynağını API'den Hive'a (Bölüm 5 Konu 22'yi hatırla) değiştirmen gerekirse, sadece UrunRepositoryImpl'i değiştirirsin — Domain ve Presentation katmanları hiç etkilenmez, çünkü onlar sadece soyut UrunRepository sözleşmesiyle çalışıyor.

3. Paralel geliştirme: Bir takım üyesi UI (Presentation) üzerinde çalışırken, başka biri API entegrasyonu (Data) üzerinde çalışabilir — aradaki soyut sözleşme (Repository), bu iki çalışmanın birbirini beklemeden ilerlemesini sağlar.

#Klasör Yapısı — Gerçek Bir Proje Organizasyonu

lib/
  data/
    urun_veri_kaynagi.dart
    urun_repository_impl.dart
  domain/
    urun.dart                    (model)
    urun_repository.dart         (soyut sözleşme)
    indirimli_urunleri_getir_usecase.dart
  presentation/
    urun_listesi_ekrani.dart
    urun_karti_widget.dart

Bu, Bölüm 1 Konu 3'te ve Bölüm 3 Konu 13'te öğrendiğimiz proje organizasyonu prensiplerinin, gerçek, ölçeklenebilir bir mimariye dönüşmüş halidir.

#Küçük Projelerde Gerekli mi?

Dürüst bir not: Bu kadar katmanlı bir yapı, küçük bir prototip veya öğrenme projesi için fazla mühendislik (over-engineering) olabilir. Bölüm 5'te yazdığımız basit örnekler (widget içinde doğrudan http.get çağırmak), küçük ölçekte tamamen makuldür. Bu mimari, uygulaman büyüdükçe, birden fazla ekran aynı veriyi kullandıkça, veya test yazma ihtiyacı arttıkça değer kazanır.

#🎯 Bu Dersten Çıkarılması Gerekenler

• Katmanlı mimari, uygulamayı Data (veri erişimi), Domain (iş mantığı) ve Presentation (görüntüleme) olmak üzere ayırır.
• Repository pattern, abstract class + implements (Dart Bölüm 7) kullanarak, veri kaynağının soyut bir sözleşmesini tanımlar — gerçek implementasyon değiştirilebilir.
• Use Case'ler, tek bir iş mantığı işlemini kapsüller, repository'den bağımsız olarak iş kurallarını uygular.
• Bu ayrım, test edilebilirlik, değişime dayanıklılık ve paralel geliştirme açısından değer sağlar.
• Küçük projelerde bu kadar katman gereksiz karmaşıklık olabilir — büyüklüğe göre karar verilmelidir.

#📝 Ödevler

• [ ] Bölüm 5'te yazdığın bir API entegrasyonunu, data/domain/presentation katmanlarına ayırarak yeniden düzenle.
• [ ] abstract class ile bir Repository sözleşmesi tanımla, gerçek (HTTP) ve sahte (test amaçlı, sabit veri döndüren) iki farklı implementasyon yaz.
• [ ] Basit bir Use Case class'ı yaz (örn. "aktif kullanıcıları filtrele"), repository'den bağımsız bir iş kuralı uygula.
• [ ] Kendi cümlelerinle, "neden Repository'yi abstract class olarak tanımlıyoruz, doğrudan somut bir class yazmıyoruz" sorusunu, test edilebilirlik bağlamında açıkla.
• [ ] Küçük bir projede bu mimariyi kullanmanın ne zaman gerekli, ne zaman "aşırı mühendislik" olacağına dair kendi kriterlerini yaz.

Sıradaki konu: Bölüm 7 — Konu 33: Dependency Injection (get_it, injectable)