# MP.SPEC

MAPO SPEC: WebApp / Sito in versione dotNetCore 8 per la gestione del MES MAPO in particolare per le gestioni SPECiali (ina ttesa di finire di migrare SITE e ADM).

Comprende funzionalità amministrative avanzate e funzionalità standard.

## Sezioni Principali

Sono gestiti
  * Articoli
  * Operatori
  * Assegnazione Operatori/Macchine a reparti
  * PODL (Promesse ODL) prima della produzione
  * ODL (Ordini di lavoro) legate ad effettive attività di produzione
  * Gestione speciale dei KIT
  * Gestione Dossier (es caso Baglietto)
  * Gestione Ricette (tramite dossier)
  * Gestione Parametri macchina
  * Gestione giacenze magazzino (ove gestite)

Ci sono anche alcune pagine speciali di admin (ad esempio FluxLogStatus, usata per deduplicare i dati di FluxLog) 

## Architettura

### Livello Dati (MP.Data)

Il layer dati centralizzato in `MP.Data` fornisce:

- **8 Repository**: Anag, Production, Dossier, FluxLog, System, MpVoc, MpMon, MpLand
- **Cache FusionCache** (Memory + Redis + DB) con invalidazione per tag
- **DI Registrations** attraverso `DataServiceCollectionExtensions` (`AddSpecDataLayer`, `AddLandDataLayer`, etc.)
- **MpDataService** come servizio singleton centrale per accesso a DB, Redis, MongoDB

### Livello Applicazione (MP.SPEC)

- **MpDataService** (Scoped, singleton in Program.cs): service wrapper sul DAL con caching FusionCache
- **Componenti Blazor Server**: layout interattivo server-side con `AddInteractiveServerComponents()`
- **API Controllers**: RecipeController, RecipeArchiveController per operazioni ricette
- **Autenticazione**: Windows Authentication (Negotiate) con Autorizzazione Blazor Server

### Livello Infrastruttura

- **SQL Server**: 4 DbContext (MoonProContext, MoonPro_VocContext, MoonPro_FluxContext, MoonPro_STATSContext)
- **MongoDB**: storage ricette
- **Redis**: caching distribuito (FusionCache) + backplane
- **OpenTelemetry**: tracing su Uptrace (abilitabile via conf)
- **MessagePipe**: broadcasting messaggi real-time

## Refactoring Completati (Giugno 2026)

### Repository Pattern - Decomposizione MpSpecController

Il grande `MpSpecController/MpSpecRepository.cs` è stato scomposto in 8 repository specialistici:

| # | Repository | Interfaccia | Metodi | DbContext |
|---|---|---|---|---|
| 1 | **Anag** | `IAnagRepository` | 26 | `MoonProContext` |
| 2 | **Production** | `IProductionRepository` | 32 | `MoonProContext` |
| 3 | **Dossier** | `IDossierRepository` | 6 | `MoonPro_FluxContext` |
| 4 | **FluxLog** | `IFluxLogRepository` | 3 | `MoonPro_FluxContext` |
| 5 | **System** | `ISystemRepository` | 7 | `MoonProContext` + `MoonProAdminContext` |
| 6 | **MpVoc** | `IMpVocRepository` | 3 | `MoonPro_VocContext` |
| 7 | **MpMon** | `IMpMonRepository` | 4 | `MoonProContext` |
| 8 | **MpLand** | `IMpLandRepository` | 6 | `MoonProContext` |

Tutti i reference a `dbController.XXX()` nei servizi sono stati rimossi. I metodi originali rimangono nel file di repository come fallback documentato.

### Migrazione FusionCache

Tutti i metodi di lettura in `MpDataService.cs` sono stati migrati al pattern `GetOrFetchAsync<T>()`:
- **L1 MemoryCache**: 1/3 della scadenza totale
- **L2 Redis (Distributed)**: TTL configurabile
- **L3 Database**: fetch diretto dal DbContext
- **Invalidazione**: per tag (es. `Utils.redisArtList`, `Utils.redisOdlByKey`)
- **48+ metodi** migrati o confermati corretti

### Fix DI e Static State (MP.AppAuth)

Risolto il null reference error originario (`Cannot provide a value for property 'AAService' on type 'CmpTop'`):

- Rimpiazzati tutti i `static IConfiguration _configuration` con `readonly` istanza nei controllers
- `AppAuthService` ora riceve i controllers via constructor DI invece di crearli con `new()`
- Registrazioni DI centralizzate in `DataServiceCollectionExtensions.cs`
- Tutti i controllers e services mp.appauth registrati come Scoped

### Build

Tutte le 10 soluzioni compilano con successo (0 errori):
MP.SPEC, MP.Data, MP.Land, MP.MON, MP.TAB3, MP.Stats, MP.INVE, MP.IOC, MP.RIOC, MP.Prog, IobConf