DbContext, DbSet ve ilgili arabirimlere daha derine inerken, neden bu uygulamalar etrafında ayrı bir "Genel" Depo uygulamanız gerektiğini merak ediyorum?
Görünüşe göre DbContext ve IDbSet ihtiyacınız olan her şeyi yapıyor ve DbContext'in içinde "İş Birimi" ni içeriyor.
Burada bir şey mi özlüyorum yoksa insanlar sebepsiz yere başka bir bağımlılık katmanı eklemekten hoşlanıyor mu?
Yanıtlar:
Aslında haklısın. DbContextçalışma düzeni biriminin IDbSetbir uygulamasıdır ve arşiv modelinin bir uygulamasıdır.
Depolar şu anda çok popüler ve gereğinden fazla kullanılıyor. Herkes bunları kullanıyor çünkü varlık çerçevesi için depo oluşturmayla ilgili düzinelerce makale var ama kimse bu kararla ilgili zorlukları tanımlamıyor.
Depo kullanmanın ana nedenleri genellikle şunlardır:
İlk neden, bir tür mimari saflık ve üst katmanlarınızı EF üzerinde bağımsız hale getirirseniz, daha sonra diğer kalıcılık çerçevesine geçebileceğiniz harika bir fikirdir. Gerçek dünyada kaç kez böyle bir şey gördün? Bu neden, EF ile çalışmayı çok daha zor hale getirir, çünkü deponuzun EF'in varsayılan olarak izin verdiği şeyleri saran birçok ek özelliği açığa çıkarması gerekir.
Aynı zamanda EF kodunu sarmak, kodunuzu daha iyi organize edebilir ve Ayrılma kaygısı kuralını takip edebilir. Benim için bu, havuzun ve çalışma biriminin tek gerçek avantajı olabilir, ancak EF ile bu kurala uymanın kodunuzu daha iyi korunabilir ve daha iyi okunabilir hale getireceğini anlamalısınız, ancak uygulamanızı oluşturmak için ilk çabanız çok daha yüksek olacaktır ve daha küçük uygulamalar için bu gereksiz karmaşıklık olabilir.
İkinci neden kısmen doğrudur. EF'nin en büyük dezavantajı, neredeyse alay edilemeyen katı mimaridir; bu nedenle, üst katmanı birim testi yapmak istiyorsanız, uygulamasının alay edilmesine izin vermek için EF'i bir şekilde sarmalısınız. Ancak bunun, burada anlattığım birçok başka sonucu vardır .
Ayende'nin blogunu takip ediyorum . NHibernate'i daha önce kullandıysanız, muhtemelen makalelerini biliyorsunuzdur. Bu adam yakın zamanda NHibernate ile depo kullanımına karşı birkaç makale yazdı, ancak NHibernate çok daha iyi alay edilebilir.
IDbSetedebilirsiniz, türetilmiş bağlamınızda özel arayüz de tanımlayabilirsiniz, ancak hepsi bu. Kodunuz ChangeTracker, Entries veya başka herhangi bir şeyi kullandığında, hepsini sarmak için büyük çaba gerektirecektir.
IQueryableveya kabul Expression<>ettiğinde, alay edilen bileşenin dışında, birim testlerle test edilemeyen yan etkileri olan mantığı tanımlarsınız.
Aynı sorunlarla mücadele ediyorum ve EF katmanlarının birim testi için alay edilebilirlik önemlidir. Ancak türetilmiş DbContext'inizin genel bir arabirim uyguladığından ve DbSet'ler yerine IDbSet'i ortaya çıkardığından emin olarak EF 4.1 DbContext'in alay edilebilir olacak şekilde nasıl ayarlanacağını açıklayan bu harika makaleye rastladım. Database First yaklaşımını kullandığım için, veritabanımız zaten mevcut olduğundan, türetilmiş DbContext'imi oluşturmak için kullanılan T4 şablonlarını değiştirerek IDbSet arayüzlerini döndürmek ve genel arayüzümden türetmek için basitçe değiştirdim. Bu şekilde, her şey kolayca alay edilebilir ve kendi Çalışma Biriminizi veya arşiv modelinizi uygulamanıza gerek kalmaz. Genel arayüzünüzü kullanmak için servis kodunuzu yazmanız yeterlidir ve ünite testine gittiğinizde,
Depoyu oluşturmanın bir nedeni, EntityFramework'dan başka bir şeye veya tam tersine geçmeye karar verirseniz DBSet ve DbContext uygulamalarını gizleyebilmenizdir.
Örneğin, NHibernate kullanıyordum ve bu çerçeveye yapılan tüm çağrıları depo sınıflarımın içine sardım. "Genel" olması için IEnumerable'ı döndürüyorlar ve depolarımda standart CRUD işlemleri var (güncelleme, silme, vb.). Uzun zamandır Entity Framework'e taşındım. Bunu yaptıktan sonra, ViewModel sınıflarımda veya ötesinde hiçbir şeyi değiştirmeme gerek kalmadı, çünkü bunlar depomu işaret ediyorlardı - sadece depomun içini değiştirmem gerekiyordu. Bu, göç ederken hayatı çok daha kolaylaştırdı.
(NHibernate'i kullandım çünkü ISeries'e bağlanıyoruz ve o zamanlar ISeries ile EF kullanan hiçbir maliyet etkili uygulamalar yoktu. Mevcut tek seçenek, DB2Connect'leri için IBM'e 12.000 $ ödemekti)