Samuele Locatelli
30 lines
1.4 KiB
Markdown
30 lines
1.4 KiB
Markdown
# Piano di Refactoring: Migrazione a FusionCache in `MpDataService.cs`
|
|
|
|
Stiamo lavorando sul progetto MP-SPEC.sln, dentro la cartella MP-SPEC (ed i progetti da cui dipende).
|
|
|
|
Voglio ottimizzare il file Data\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.
|
|
|
|
## Strategia di Migrazione
|
|
- **Metodo Standard**: `GetOrFetchAsync<T>(string operationName, string cacheKey, Func<Task<T>> fetchFunc, TimeSpan expiration, params string[] tagList)`.
|
|
- **Invalidazione**: Utilizzare i tag tramite `FlushCacheByTagsAsync`.
|
|
|
|
## Stato Avanzamento
|
|
|
|
### Fase 1: Analisi e Mapping (Completata)
|
|
|
|
### Fase 2: Refactoring Metodi di Lettura (Cache-aside)
|
|
|
|
|
|
#### 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.
|