İş katmanında önbellekleme vs Veri katmanında önbellekleme

Ben her zaman DAL'de önbelleklemenin yapıldığı projeler üzerinde çalıştım, temelde sadece veritabanına çağrı yapmak üzereyken, verilerin önbellekte zaten olup olmadığını kontrol eder ve eğer öyleyse çağrı yapmaz ve bunun yerine bu verileri döndürür.

Daha yeni iş katmanında önbellekleme hakkında okudum, bu nedenle temel olarak tüm iş nesnelerini önbelleğe aldım. Hemen görebildiğim bir avantaj, çok daha iyi tepki süreleri.

Birini diğerinden ne zaman tercih edersin? ve İş Katmanında önbellekleme yaygın bir uygulama mı?

c# design design-patterns caching

— Emma
kaynak

Uygulamalarınızın performansı, iş katmanındaki önbelleğe alma işleminin bir havuz veya DAL katmanına yapılan ek bir çağrının netliğini önlemek yerine tercih edilmemesi açısından çok mu önemlidir?

— JDT

Hayır değil ve cevapları okuduktan sonra, sadece DAL’de önbelleklemeye devam edeceğimi düşünüyorum. Şerefe.

— Emma,

Business Layer'ınızın üzerinde önbelleğe almayı düşünmeniz ve ölçeklemeyi düşünmeniz gerekir.

— AK_

Yanıtlar:

Bu, kesin bir cevap için muhtemelen çok geniştir. Şahsen, bir veri erişim katmanının önbellekleme için daha iyi bir yer olduğunu hissediyorum, çünkü çok basit olması gerekiyordu - kayıtlar girip çıkıyor ve bu kadar.

Bir işletme katmanı birçok yüksek karmaşıklık kuralı uygular; bu nedenle , aynı sınıftaki (veya aynı yöntemdeki) birden fazla nesne tutarlılığı sorunlarına ek olarak, nesne başına kullanılabilirlik sorunlarını da yönetmesi gerekmiyorsa daha iyidir. SRP’nin açık bir ihlali olması.

(Tabii ki, hizmet sınıflarımın aynı anda hem önbelleğe alma hem de konfigürasyon yapmaya çalıştıklarında yönetilemez karmaşıklığa dönüştükten sonra bu kavrayışa ulaştım. Deneyimden daha iyi bir öğretmen yok, ancak fiyat çok fazla.)

— Kilian Foth
kaynak

Önbellek neden karmaşık olmak zorunda? AOP ve birkaç ek açıklama ile yapılabilir. Hala bir SRP ihlali mi? DAL’da bittiğinde neden olmasın? Ayrıca IMHE Önbelleklenecek "çok karmaşık" servis sınıflarını hiç görmedim; karmaşıklığından bağımsız olarak, bir hizmet kara kutu olarak görülebilir ve sonucu önbelleğe alınabilir

— user1075613

Veri erişimi ve kalıcılık / depolama katmanları, önbellekleme için karşı konulmaz doğal yerlerdir. G / Ç'leri yapıyorlar, önbellekleme yapmak için onları kullanışlı ve kolay bir yer haline getiriyorlar. Neredeyse her DAL veya kalıcılık katmanına, olgunlaştıkça önbellekleme işlevi verileceğini, en başından beri bu şekilde tasarlanmadığı takdirde görüyorum.

Sorun niyet . DAL ve kalıcılık katmanları nispeten düşük seviyeli yapılarla ilgilidir - örneğin, kayıtlar, tablolar, satırlar ve bloklar. "İşletme" veya uygulama katmanı nesnelerini göremiyorlar veya daha üst seviyelerde nasıl kullanıldığı konusunda çok fazla fikir sahibi değiller. Bir avuç satır veya bir düzine bloğun okunduğunu veya yazıldığını gördüklerinde, temsil ettikleri açık değildir. "Şu anda analiz ettiğimiz Jones hesabı", uygulamanın yalnızca bir kez ihtiyaç duyduğu ve tekrar yönlendirmeyeceği bazı temel vergi oranı referans verilerinden çok farklı görünmüyor. " Bu katmanda veri veridir.

DAL / kalıcılık katmanında önbellekleme, "soğuk" vergi referansı verisinin burada oturuyor olması, anlamsız bir şekilde 12.2 MB önbellek işgal etmesi ve aslında yalnızca bir dakika içinde yoğun bir şekilde kullanılacak bazı hesap bilgilerinin yerinin değiştirilmesi. En iyi önbellek yöneticileri bile, daha üst düzey veri yapıları ve bağlantıları hakkında yetersiz bilgi edinmekte ve hangi işlemlerin yakında gerçekleşeceği hakkında çok az bilgi edinmekte ve tahmin algoritmalarına geri dönmektedir .

Buna karşılık, uygulama veya işletme katmanı önbelleklemesi neredeyse hiç düzgün değil. İş kodunu daha karmaşık hale getiren önbellek yönetimi işlemlerini veya ipuçlarını diğer iş mantığının ortasına yerleştirmeyi gerektirir. Ancak takas: Makro düzeyindeki verilerin nasıl yapılandırıldığı ve hangi işlemlerin gerçekleştiği hakkında daha fazla bilgi sahibi olmak, en iyi ("bekar" ya da "Bélády Min") önbellekleme verimliliğini tahmin etmek için çok daha iyi bir fırsata sahip.

Önbellek yönetimi sorumluluğunun işletme / uygulama koduna dahil edilip edilmemesi mantıklı bir çağrıdır ve uygulamalara göre değişir. Pek çok durumda, DAL / kalıcılık katmanlarının onu "mükemmel derecede doğru" olarak elde edemeyeceği biliniyorsa, tradeoff oldukça iyi bir iş yapabiliyor, bunu mimari olarak "temiz" ve çok daha yoğun bir şekilde test edilebilir şekilde yapıyorlar. ve bu düşük seviyeli yakalama işletme / uygulama kodunun karmaşıklığını artırmaktan kaçınır.

Düşük karmaşıklık, daha yüksek doğruluk ve güvenilirliği teşvik eder ve pazara daha kısa sürede ulaşır. Bu genellikle büyük bir tradeoff olarak kabul edilir - daha az mükemmel önbellekleme, ancak daha iyi kalite, daha zamanında iş kodu.

— Jonathan Eunice
kaynak

Yanıt için teşekkürler. Sizinkinin ve diğerlerinin cevaplarını okuduktan sonra, kesinlikle iş katmanında önbelleklememe gerek olmadığını düşünüyorum. Sadece ürünün genel karmaşıklığına katkıda bulunacaktır.

— Emma,

"Katmanlar" modeliyle ilgili bir sorun, etkili önbellekleme mekanizmalarının çoğu zaman tek bir katmanda bulunmayan bilgileri kullanması gerektiğidir. Bir iş katmanına sahip olmanın, genel "plan" hakkındaki veri katmanına "ipuçlarını" iletmesinin ne olduğunu düşünüyorsunuz? Veri katmanı başlangıçta bu tür ipuçlarını görmezden gelebilir, ancak bir darboğaz bulunursa, bazı ipuçları verildiğinde önbellek stratejilerini işe özel bir şekilde değiştirecek bir mantık eklenebilir.

— supercat

Mükemmel nokta, süper kedi. Bir ipucu / pragma stratejisinden bahsedecektim ama cevap çoktan gelmişti. Ama kesinlikle haklısın. İş katmanı, önbelleklerin nasıl önceliklendirileceği veya “neyin sabitlenmesi gerektiği” hakkında daha düşük katmanlara işaret eder; iş kodunu hepsini yapmadan veya kendi depolamasını yönetirken çok fazla yakalanmak için daha yüksek düzeyde önbelleğe almanın oldukça yaygın / yararlı bir yoludur hiyerarşi.

— Jonathan Eunice,

@JonathanEunice: İpuçlarıyla ilgili hoş bir şey, kodun başlangıçta onlarla çok fazla bir şey yapması gerekmediğidir. Pek çok sistem, performanslarına hâkim olan birkaç belirgin darboğaza sahiptir, ancak hangilerinin önemli olduğu konusunda kötü olup olmayacağını tahmin etmek zor olabilir. Birkaç kritik noktaya az miktarda çirkin önbellek mantığı eklemek, gerçekten önemli olmayan yerlere bir sürü önbellek mantığı atmaktan daha iyi olabilir.

— supercat

Kesinlikle. Özellikle, kalıcılık / erişim katmanında zaten "oldukça iyi" düşük seviye önbelleğe alma işleminiz varsa. "Oldukça iyi" den "gerçekten iyi" ye geçmek için yalnızca ek bir önceliklendirme bilgisine ihtiyacınız olabilir.

— Jonathan Eunice

DAL'de önbellekleme basit ve basittir

DAL'iniz merkezi veri erişim katmanıdır, yani tüm veri erişiminin oradaki sınıflar aracılığıyla kontrol edilebileceği anlamına gelir. Hem okuma hem de devam etme bu katmanlarda gerçekleştiğinden, değişiklik yapıldığında önbellek girişlerini temizlemek veya güncellemek de aynı derecede kolaydır.

İşletmede önbellekleme esnek

İşi önbelleğe almak, geliştiricilere bir nesnenin somut kullanımının önbellekten faydalanıp faydalanmayacağını belirleme esnekliği sağlar. Uygulamanın yapısına bağlı olarak arka uç hizmetler veya otomatik işlemler, diğer bölümlerde önbelleğe alınan verileri değiştirebilir. İşyerinde önbelleğe alma ile bir geliştirici, belirli bir iş nesnesinin olası eski veriye sahip olup olmayacağını ve performans elde edip edemeyeceğini veya performans pahasına bir iş nesnesinin en güncel durumuna sahip olup olmadığını belirleyebilir.

— JDT
kaynak