I livelli di accesso ai dati e di persistenza / archiviazione sono luoghi naturali irresistibilmente per il caching. Stanno facendo gli I / O, rendendoli pratici e facili da inserire nella cache. Immagino che quasi ogni livello DAL o di persistenza, dato che maturi, abbia una funzione di caching - se non è progettato in questo modo sin dall'inizio.
Il problema è intent . I livelli DAL e di persistenza trattano con costrutti di livello relativamente basso, ad esempio record, tabelle, righe e blocchi. Non vedono gli oggetti "business" o layer di livello applicativo o hanno una visione approfondita di come vengono utilizzati a livelli più alti. Quando vedono una manciata di righe o una dozzina di blocchi letti o scritti, non è chiaro che rappresentino. "L'account Jones che stiamo analizzando al momento" non sembra molto diverso da "alcuni dati di riferimento sulla tassazione di base di cui l'app ha bisogno solo una volta e ai quali non farà più riferimento". A questo livello, i dati sono dati sono dati.
La memorizzazione nella cache del livello del livello DAL / persistenza presenta i dati di riferimento fiscali "freddi" che si trovano lì, occupano inutilmente 12,2 MB di cache e sostituiscono alcune informazioni sull'account che verranno utilizzate in modo intensivo in appena un minuto. Persino i migliori gestori di cache hanno a che fare con scarse conoscenze delle strutture e delle connessioni dati di livello superiore e non si capiscono le operazioni in arrivo, quindi ritornano a algoritmi di congestione .
Al contrario, il caching a livello di applicazione o di business non è così semplice. Richiede l'inserimento di operazioni di gestione della cache o suggerimenti nel mezzo di altre logiche di business, il che rende il codice aziendale più complesso. Ma il compromesso è: Avere una maggiore conoscenza di come sono strutturati i dati a livello macro e quali operazioni stanno arrivando, ha un'opportunità molto migliore per approssimare l'efficienza di caching ottimale ("chiaroveggente" o "Bélády Min").
Se l'inserimento della responsabilità di gestione della cache nel codice business / dell'applicazione ha senso è un giudizio, e varierà in base alle applicazioni. In molti casi, anche se è risaputo che i livelli DAL / persistenza non riescono ad avere "perfettamente ragione", il compromesso è che possono fare un buon lavoro, che lo fanno in modo architettonicamente "pulito" e molto più intensamente testabile e questa cattura a basso livello evita l'aumento della complessità del codice business / app.
Una minore complessità incoraggia una maggiore correttezza e affidabilità e un time-to-market più rapido. Questo è spesso considerato un ottimo compromesso: meno cache perfetta, ma un codice aziendale di migliore qualità e più tempestivo.