Kalıcılık-cahil nesneler tembel yüklemeyi uygulayabilir mi?

Kalıcı Cehalet , tek bir sorumluluk ilkesinin uygulamasıdır; bu, uygulamada Etki Alanı Nesneleri'nin ( DO ) kalıcılıkla ilgili kod içermemesi gerektiği yerine yalnızca etki alanı mantığı içermesi anlamına gelir .

a) Bunun alt katmanlarla (yani kalıcılık katmanlarıyla) temas eden kodun , bir iş mantığı katmanının diğer sınıflarında ( OC ) etki alanı modelinin dışında yaşadığını varsayar mıyım?

b) altında benim varsayım ise a) doğrudur, o zaman DO diyelim ki, Customerasla gibi yöntemleri içerir GetCustomersya GetCustomerByID?

c) a) ve b) altındaki varsayımlarım doğruysa ve Customeretki alanı nesnesinin bazı özellikleri için tembel yükleme kullandığını varsayarsak , o zaman bir noktada Customerdahili mantığın OC ile temas etmesi gerekir ; bu da değiştirilen verileri alır. Ancak , zorunlu verileri almak Customeriçin OC ile iletişime geçmesi gerekiyorsa , Etki Alanı Nesnelerinin kalıcılıkla ilgili mantık içermediğini gerçekten iddia edemeyiz ?!

teşekkür ederim

Jkohlhepp'E YANIT

1) Ben varsayalım OrderProviderve CustomerProvidersınıflar iş mantığı katmanında bulunur?

2) Cevabınızdan, b) altındaki varsayımlarımın doğru olduğuna karar veriyorum ?

3)

... bazı özel siparişler alanının doldurulup doldurulmadığını veya boş olup olmadığını kontrol ederdim. Boşsa ...

Ama anlayabildiğim kadarıyla, alan kodunun özel orderalanın doldurulup doldurulmadığını kontrol etmesi gerektiğinde ve eğer değilse, OrderProvider ile iletişime geçerek PI prensibini zaten ihlal ediyoruz ?!

Kalıcılık cehaletiyle ilgili A ve B varsayımlarınızda doğru olduğuna inanıyorum.

Veritabanı nesnelerinin tembel yüklemesini en iyi nasıl gerçekleştireceğiniz, büyük ölçüde sizin sorununuza ve uygulamanıza bağlıdır. Ancak, kalıcılık ve etki alanı mantık sınıfları arasındaki endişelerin ayrılığını korurken tembel yüklemenin nasıl yapılacağı konusunda genel bir cevap vermeye çalışacağım.

Aşağıdaki sınıfları kullanarak kalıcılık bilgisizliği uygulama eğilimindeyim:

• Alan sınıfları - ör. Müşteri
• Sağlayıcı / havuz sınıfları - örneğin, CustomerProvider
• Genel veritabanı sorgulama sınıfları - örneğin DatabaseQuery

DatabaseQuery sınıfı, veritabanını sorgulamak ve elde edilen verileri DataTable gibi genel bir sonuç kümesine birleştirmek için veritabanı sürücüsünü kullanmaktan sorumlu olacaktır. CustomerProvider, veritabanına karşı SQL yürütmek için DatabaseQuery sınıfını kullanmaktan ve Müşteri örneklerini birleştirmek için bu SQL'in sonuçlarını kullanmaktan sorumlu olacaktır. Müşteri, müşterilerle ilgili verileri ve mantığı içeren "saf" etki alanı nesnesi olacaktır.

Sağlayıcı sınıflarının iş katmanında mı yoksa veri katmanında mı olması gerektiği konusunda güçlü bir fikrim yok. Her ikisi için de bir dava görebilirim. Önemli olan, sorumlulukları sınıflar arasında ayırmanızdır.

Şimdi tembel yüklemeyi tartışalım. Diyelim ki Müşterinin bir Emir koleksiyonuna sahip olmasını istedim, ancak tüketici bunlara erişmeye çalışmadığı sürece Siparişler'i veritabanından çıkarmak istemiyorum. Müşteri üzerinde Siparişler adlı bir mülk oluştururdum. Bu özelliğin alıcısında, bazı özel siparişler alanının doldurulup doldurulmadığını veya boş olup olmadığını kontrol ederdim. Boşsa, siparişleri bir OrderProvider kullanarak veritabanından yükleyin. Aksi takdirde, zaten yüklenmiş olan koleksiyonu iade edin.

Bence, kontakt OrderProvider Müşterinin ihtiyacı yok değil PI ihlal. Müşteri hala siparişleri nasıl aldığını bilmiyor . Sadece bunları OrderProvider'dan aldığını biliyor. Müşteri'yi OrderProvider'dan ayırmak için başka nedenler olabilir, ancak PI'nin burada bir sorun olduğunu düşünmüyorum.

Bu, manuel olarak kalıcılık bilgisizliği yaptığınızı varsayar. Entity Framework veya Hibernate gibi bir ORM çerçevesi kullanıyorsanız, bu çerçeveler genellikle tembel yüklemeyi otomatik olarak destekleme özelliklerine sahiptir.

Etki alanı nesnelerini dolduran bir telleşme sınıfınız var (örneğin, "depo" adı verilen bir şey). Tembel yükleme veya istediğiniz tür önbellek tutarlılığı şemasını uygulayabilirsiniz ve etki alanı nesneleri akıllıca değildir. Etki alanı nesnelerini doldurma sorumluluğunu etki alanı nesneleri olmaktan ayırıyorsunuz.