Pola Repositori vs Pembuatan Obyek DAL


9

Sejauh yang saya pelajari, IRepositoryseharusnya berisi CRUD. Kemudian kita mewarisi ini IRepositorydi Antarmuka kami yang lain seperti IProductdan menerapkan IProductkelas beton ProductRepository, dengan metode seperti GetAllProducts(), Top5Products().

Kita juga bisa melakukan hal yang sama dengan arsitektur n-tier. seperti, Membuat DAL Class Librarydan di dalamnya mendefinisikan kelas Productdengan metode seperti GetAllProducts(), Top5Products().

Dalam kedua DAL.Productdan Repo.ProductRepositorykelas kita menginisialisasi DB Contextdari Entity Frameworkdan query data yang relevan kami.

Pemanggilannya sama dalam kedua metode Repo.ProductRepositoryatau DAL.ProductdariBLL

Mengingat kesamaan ini, pertanyaan saya apa manfaat Repos? Aku bisa melakukan hal yang sama dengan mudah banyak menggunakan arsitektur n-tier dengan ( Controller, BLL Class Library, DAL Class Library).


@Neil Saya pikir OP akrab dengan DAL dan bertanya apakah repositori hanyalah antarmuka lain untuk melakukan hal yang sama atau jika lebih
Christophe

@ Christophe tepatnya, saya bingung soal ini. Jika kita bisa melakukan hal yang sama di DAL mengapa menggunakan pola repo?
M. Arslan

Jawaban:


7

Pemahaman saya adalah:

  • DAL (Data Access Layer) mengacu pada lapisan dalam perangkat lunak Anda yang berada di antara teknologi kegigihan Anda dan logika aplikasi Anda. Tujuannya adalah untuk memisahkan masalah akses data dari masalah aplikasi Anda. Ini adalah konsep umum .

  • Repositori adalah konsep dari DDD (Domain Driven Design).

Dalam DDD, Repositori bertanggung jawab untuk mengenkapsulasi semua masalah akses data untuk Agregat tertentu . Ini datang dengan tanggung jawab untuk memastikan konsistensi selama membaca dan menulis Agregat. Dan Agregat adalah pengelompokan Entitas terkait (misalnya Product, Store, dll).

Jadi, suatu Repositori secara khusus menyadari masalah kegigihan dan konsistensi Agregatnya. DAL umum Anda kemungkinan besar akan terdiri dari Gudang khusus

TL; DR;

  • DAL adalah istilah umum untuk mengabstraksi masalah Akses Data.
  • Repositori adalah konsep yang serupa, tetapi lebih spesifik, dari DDD.
  • DAL Anda kemungkinan akan terdiri dari beberapa Repositori.

4
Repositori juga merupakan istilah yang digunakan secara lebih umum di luar DDD untuk merujuk pada kumpulan objek di-memori yang mencerminkan catatan basis data. Dalam konteks ini, ia berada di antara DAL dan Business Logic Layer. Lihat martinfowler.com/eaaCatalog/repository.html
Robert Harvey

Mengapa semua orang mencoba memberikan kredit DDD untuk semuanya ?!
TheCatWhisperer

1
Hari ini saya belajar: P
MetaFight

2

Anda membandingkan dua konsep yang berbeda dan saling melengkapi:

  • The Data Access Layer adalah lapisan arsitektur yang bermaksud untuk akses abstrak data. Itu tidak mengatakan bagaimana akses akan diabstraksikan.
  • The Repository adalah pola tertentu yang dimiliki oleh DAL (lihat daftar pola pada akhir link ini ). Ia mengatakan dengan tepat bagaimana abstrak akses khusus ke data: dengan menawarkan koleksi seperti antarmuka ke penyimpanan data.

DAL dalam contoh Anda

Menariknya, dalam contoh perpustakaan kelas Anda, DAL.Producttampaknya menjadi repositori. Jadi itu normal bahwa Anda tidak benar-benar melihat perbedaan: dari sudut pandang implementasi itu sama (dalam kasus khusus ini).
Tetapi tidak harus; DAL dapat diimplementasikan secara berbeda, misalnya:

  • catatan aktif yang mengandalkan lapisan abstraksi basis data.
  • objek domain anemia (perhatian, anti-pola!) yang diperoleh dari gateway data baris
  • atau, mengapa tidak, objek domain yang diperoleh dari objek kueri yang berbeda, di mana setiap kueri akan menerapkan cara tertentu untuk mengambil objek
  • repositori
  • campuran dari semua itu

Apa yang berbeda untuk repositori

Konsep repositori tidak tergantung pada model arsitektur dan implementasinya. Anda tidak perlu memikirkan lapisan atau basis data. Yang perlu Anda ketahui ketika Anda mendesain domain Anda, adalah bahwa objek Anda berada di repositori yang merupakan jenis khusus dari koleksi penyihir yang menawarkan kegigihan. Ini membuatnya sangat cocok untuk desain domain dan menjelaskan mengapa mereka adalah elemen kunci dari Desain Domain Driven .

Dalam DDD, repositori memiliki beberapa aturan yang harus dihormati: mereka memberikan akses ke agregat (entitas independen, atau sekelompok entitas terkait yang bergantung pada akar agregat) dan ada satu repositori tunggal per agregat.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.