# 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.