LINQ ve Veri Erişim Katmanı

Kendime her zaman iş mantığı ve kullanıcı arayüzü kodumdan tamamen ayrı bir 'katman' içinde herhangi bir veri erişim kodunu kullanmayı öğrettim. Bu benim için her zaman çok iyi bir mimari oldu ve gördüğüm 'kurallar' veya en iyi uygulamalar hala bu kodlama tarzına, özellikle de Tek Sorumluluk Prensibine uymayı başardı .

Ev projelerimin çoğu için, her zaman açık kaynak yapmayı düşündüğüm kendi ORM'imi kullanardım. Ancak o zamandan beri, ORM'imin çalışma şekline çok benzeyen LINQ mevcut oldu (ama .. daha iyi).

Daha önce kendi ORM ile yapabileceğim hiçbir şey yok, şimdi LINQ ile yapamıyorum (REST entegrasyonunun bitleri hariç). Benim sorum şu; Veri Erişim Katmanım LINQ nedir? Artık bu katmana ihtiyacım var mı? BLL'im doğrudan LINQ ile mi konuşmalı? Yoksa bu kötü uygulama hala mı?

Düzenle:

Orijinal soru LINQ to Entities'den bahsediyordu, ancak LINQ to SQL ile ilgili birçok ilginç cevap var. Her ikisinin de insanların düşünceleri nelerdir? LINQ to SQL gerçekten bir DAL yerini alamaz, ancak Entity Framework olabilir toplamak?

BIN'nize sadece LINQ sorguları koyabilirsiniz, ancak bu kod çoğaltmasına neden olabilir. Hala LINQ sorguları için bir sarıcı olacak depolar oluşturmak istiyorum. Bu, Veritabanı kodunu BLL kodundan ayırır ve veri erişim kodunuzu değiştirmeye karar verdiğinizde (örn. Dapper'a veya önceden derlenmiş sorgulara geçtiğinizde) yararlı olacaktır.

Depolar kolayca taklit edilebildiğinden, birim testine de yardımcı olacaktır .

Hala bir DAL'niz olabilir, yalnızca daha önce kullandığınız yerine LINQ to SQL kullanabilir. Zaten böyle yapıyorum. BLL'nizin verilere erişmek için doğrudan LINQ to SQL kullanmasına izin vermeyin.

Linq veri erişimi ile ilgili değildir, linq'i herhangi birine doğru kullanabilirsiniz IEnumerable.

İlk olarak veritabanını düşünmeden başvurunuzu tasarlamaya çalıştınız mı? Yani, uygulamanızı uygulayın ve bir tür depo kullanın. Sonra bu depoları uygulamak için hangi tekniği kullanırsanız kullanın. Bu şekilde, istediğiniz veri erişim katmanını ekleyebileceğiniz tamamen ayrılmış bir çözüme sahip olursunuz.

Bu veri erişim katmanında kendi ORM'nizi kullanabilir veya Linq to sql kullanabilirsiniz, veri erişim katmanı tanımladığınız depoları uyguladığı sürece önemli değildir.

"İş mantığı katmanınızın" işlemleri ve sorgu performansını ele almasını istemiyorsanız, yine de bir DAL'ye ihtiyaç vardır.

LINQ, sorgu bildirimini tasarım zamanı (derleyici denetimli) olarak adlandırır.

LINQ sorgu sağlayıcıları (LinqToSql ve LinqToEntities gibi), bildirilen bu sorguların çalışma zamanı sql metnine hala çalışma zamanını dönüştürür. Sonra DBMS hala çalışma zamanı sorgu yorumlama, çalışma zamanı sorgu planı oluşturma vb yapar.

Bunlar DAL'ın sadece küçük bir kısmı.