Samuele Locatelli
50 lines
3.0 KiB
Markdown
50 lines
3.0 KiB
Markdown
# Piano di Refactoring: Migrazione a FusionCache in `MpDataService.cs`
|
|
|
|
## Obiettivo
|
|
Migrare la logica di caching manuale (Redis + DB) verso l'utilizzo di `IFusionCache` per implementare un approccio multi-layer (Memory + Redis + DB), standardizzando l'accesso ai dati.
|
|
|
|
## Analisi dello stato attuale
|
|
- **Classe target**: `MP.SPEC\Data\MpDataService.cs`
|
|
- **Pattern attuale**: Molti metodi utilizzano manualmente `redisDb.StringGetAsync` e `redisDb.StringSetAsync` con serializzazione JSON manuale.
|
|
- **Metodo Standard**: `GetOrFetchAsync<T>(string operationName, string cacheKey, Func<Task<T>> fetchFunc, TimeSpan expiration, params string[] tags)`.
|
|
|
|
## Strategia di Migrazione
|
|
|
|
### 1. Identificazione Metodi Target
|
|
Andrò a mappare tutti i metodi in `MpDataService.cs` che:
|
|
- Utilizzano `redisDb` direttamente per la lettura/scrittura.
|
|
- Gestiscono manualmente la serializzazione/deserializzazione con `JsonConvert`.
|
|
- Gestiscono manualmente il fallback dal Redis al DB.
|
|
|
|
### 2. Classificazione Metodi
|
|
I metodi verranno suddivisi in:
|
|
- **Lettura (Cache-aside)**: Metodi che recuperano dati. Questi saranno i candidati principali per `GetOrFetchAsync`.
|
|
- **Scrittura/Invalidazione**: Metodi che aggiornano il DB e devono invalidare la cache (es. `AnagGruppiUpsert`, `ArticoliUpdateRecord`). Questi dovranno utilizzare `_cache.RemoveByTagAsync` o `_cache.RemoveAsync`.
|
|
|
|
### 3. Piano di Implementazione (Step-by-Step)
|
|
|
|
#### Fase 1: Analisi e Mapping
|
|
- [ ] Identificare ogni occorrenza di `redisDb.StringGet` / `StringGetAsync` in `MpDataService.cs`.
|
|
- [ ] Verificare se la chiave di cache utilizzata è gestita tramite `Utils.redis...`.
|
|
|
|
#### Fase 2: Refactoring Metodi di Lettura
|
|
Per ogni metodo di lettura individuato:
|
|
- [ ] Sostituire la logica `if (rawData.HasValue) { ... } else { ... }` con la chiamata a `GetOrFetchAsync`.
|
|
- [ ] Assicurarsi che il `fetchFunc` esegua la chiamata al `dbController`.
|
|
- [ ] Configurare correttamente il `TimeSpan expiration` (usando le costanti esistenti come `redisLongTimeCache` o `redisShortTimeCache`).
|
|
- [ ] Aggiungere i tag appropriati per permettere l'invalidazione granulare.
|
|
|
|
#### Fase 3: Refactoring Metodi di Scrittura e Invalidazione
|
|
- [ ] Sostituire le chiamate manuali a `ExecFlushRedisPattern` o `redisDb.KeyDelete` con i metodi di invalidazione di `IFusionCache`.
|
|
- [ ] Utilizzare i tag per invalidare gruppi di dati correlati invece di pattern Redis generici quando possibile.
|
|
|
|
#### Fase 4: Verifica
|
|
- [ ] Verificare la compilazione della soluzione tramite script PowerShell.
|
|
- [ ] Controllare che i log (NLog) continuino a riflettere correttamente le operazioni.
|
|
|
|
## Rischi e Mitigazioni
|
|
- **Rischio**: Discrepanza nelle chiavi di cache tra vecchio e nuovo sistema.
|
|
- *Mitigazione*: Utilizzare rigorosamente le costanti in `Utils.redis...` per garantire che le chiavi siano identiche o gestite dal nuovo sistema.
|
|
- **Rischio**: Errori di serializzazione.
|
|
- *Mitigazione*: `FusionCache` gestisce la serializzazione, ma è necessario assicurarsi che i tipi di ritorno siano compatibili con le aspettative dei chiamanti.
|