Havuz Kalıbı ve DAL Nesnesi Oluşturma

Bildiğim kadarıyla IRepositoryiçermelidir CRUD. Sonra bu miras IRepositorygibi diğer Interfaces IProductve uygulamak IProductbeton sınıfı ProductRepositorygibi yöntemlerle, GetAllProducts(), Top5Products().

Aynı şeyi n katmanlı mimari ile de yapabiliriz. Gibi, Oluşturma DAL Class Libraryve içinde , Productgibi yöntemlerle bir sınıf tanımlar .GetAllProducts()Top5Products()

İkisinde de DAL.Productve Repo.ProductRepositorybiz başlatmak sınıfların DB Contextarasında Entity Frameworkve ilgili verileri sorgulamak.

Arama iki benzer Repo.ProductRepositoryya da DAL.ProductyöntemleriBLL

Bu benzerlikler göz önüne alındığında, sorum Repos'un faydası nedir? Birlikte n-katmanlı mimariler kullanarak çok kolaylıkla aynısını yapabilirsiniz ( Controller, BLL Class Library, DAL Class Library).

Benim anlayışım:

• DAL (Veri Erişim Katmanı) , yazılımınızda kalıcılık teknolojiniz ile uygulama mantığınız arasında bulunan bir katmanı ifade eder . Amacı, veri erişimi ile ilgili endişeleri diğer uygulama endişelerinizden ayrı tutmaktır. Bu bir olan genel bir kavram.

• Depo , DDD'den (Etki Alanına Dayalı Tasarım) bir kavramdır.

DDD'de bir Veri Havuzu , belirli bir Toplam için tüm veri erişimi endişelerini kapsüllemekten sorumludur . Bu, Agrega'nın okuma ve yazma işlemleri sırasında tutarlılığı sağlama sorumluluğuyla birlikte gelir. Ve Agrega ilgili oluşumlar (örneğin, bir gruptur Product, Storevs.).

Yani, bir Repository's.Benim özellikle onun Agregaların kalıcılık ve tutarlılık kaygıların farkında. Sizin genel DAL büyük olasılıkla oluşacak spesifik Arşivleri

TL; DR;

• DAL , Veri Erişimi endişelerini ortadan kaldırmak için kullanılan genel bir terimdir.
• Depo , DDD'den benzer, ancak daha spesifik bir kavramdır.
• DAL'niz büyük olasılıkla birkaç Depodan oluşacaktır.

İki farklı ve tamamlayıcı kavramı karşılaştırıyorsunuz:

• Veri Erişim Katmanı verilerine soyut erişim niyetinde mimari bir katmandır. Erişimin nasıl soyutlanacağını söylemez.
• Depo DAL (sonunda kalıplarının listesini görmek ait spesifik bir kalıptır bu bağlantı ). Verilere belirli bir erişimin nasıl soyutlanacağını tam olarak anlatır: veri deposuna arayüz gibi bir koleksiyon sunarak.

Örneğinizdeki DAL

İlginç bir şekilde, sınıf kitaplığı örneğinizde DAL.Productbir havuz gibi görünüyor. Bu nedenle, gerçekten bir fark görmemeniz normaldir: uygulama açısından aynıdır (bu özel durumda).
Ama buna gerek yok; Bir DAL farklı şekilde uygulanabilir, örneğin:

• veritabanı soyutlama katmanına dayanan etkin kayıtlar .
• satır veri ağ geçidinden elde edilen anemik etki alanı nesneleri (dikkat, anti-pattern!)
• veya neden olmasın, her bir sorgunun nesneyi almak için belirli bir yol uygulayacağı farklı sorgu nesnelerinden alınan etki alanı nesneleri
• depoları
• bunların hepsinin bir karışımı

Depo için farklı olan nedir

Havuz kavramı, mimari modelden ve uygulamadan bağımsızdır. Katmanları veya veritabanını düşünmenize gerek yoktur. Etki alanınızı tasarlarken bilmeniz gereken tek şey, nesnelerinizin özel bir koleksiyon cadı deposu içinde kalıcılık sunan olmasıdır. Bu, onları etki alanı tasarımı için çok uygun hale getirir ve neden Etki Alanı Odaklı Tasarımın önemli bir öğesi olduklarını açıklar .

DDD'de depoların saygı duymak için daha fazla kuralı vardır: agregalara (bağımsız bir varlık veya toplam köke bağımlı bir grup ilişkili varlık) erişim sağlarlar ve toplamda tek bir havuz vardır.