.NET 10 · MariaDB · Entity Framework · Validazione architetturale
Il peso è certo.L'architettura che lo governa deve esserlo nelle decisioni.
State costruendo la generazione di macchine di pesatura che venderete per i prossimi vent'anni. Il momento per validare l'architettura dati non è dopo il primo problema in linea. È adesso, mentre una scelta si può ancora cambiare.
Non state scegliendo un ORM.
State decidendo cosa dovrà reggere concorrenza, più device sullo stesso dato e query sotto carico — e restare vero per vent'anni.
Avete una base che funziona. Il rischio arriva dopo, quando smette di bastare.
Siete passati a Entity Framework da pochi mesi, su .NET 10 e MariaDB. Un vostro collega ha già disegnato un'architettura dati comune alle macchine automatiche e non automatiche. Non partite da zero: avete qualcosa di tangibile su cui ragionare — ed è esattamente la fase giusta per farlo.
Il tema non è "far funzionare un database". È tutto quello che c'è tra questo e sfruttare Entity Framework davvero: concorrenza, dati condivisi da più terminali, il salto dal LINQ che scrivete alla query SQL che viene generata, l'ottimizzazione quando i tempi contano, le migrazioni, le decisioni che poi restano nel prodotto.
«Tra riuscire a fare un database e capire bene Entity Framework, come lavora e come sfruttarlo a pieno, passa un po' di strada.»Parafrasi fedele — dal confronto con il team tecnico Coop Bilanciai, 7 luglio 2026
La stessa strategia dati deve reggere due carichi opposti.
- Non automaticaUn terminale collegato a una pesa: la pesatura di un camion con container. Ritmo umano, schema semplice — a volte dieci tabelle, tre o quattro usate di frequente.
- AutomaticaUn impianto in linea che pesa fino a 200 pezzi al minuto. Non si deve bloccare: la query dev'essere veloce, ottimizzata, asincrona. Conta la stabilità, non l'interfaccia.
- Il punto criticoPC, PLC e scheda bilancia — con la stampante, quattro entità — devono sincronizzarsi a inizio lavorazione nel minor tempo possibile. Più è breve la lettura dal database, più è rapida la linea.
Un'architettura non validata continua a funzionare. Finché non incontra il carico vero.
Lo avete detto voi: più andate avanti a sviluppare, più diventa difficile cambiare. Oggi avete qualcosa di sviluppato ma nessuna macchina ancora installata. È la finestra in cui una correzione costa una decisione — non un rifacimento.
Gli scenari che oggi non si possono ancora simulare arrivano tutti: più terminali che scrivono e leggono lo stesso dato, chi arriva prima, i volumi reali sulle query, le migrazioni, l'omologazione. Ogni macchina messa sul mercato da dicembre 2027 passerà da test e fascicoli tecnici. Le scelte fatte oggi verranno lette allora.
Non lezioni astratte. Decisioni prese sul vostro progetto reale.
Si entra sul codice che avete già scritto. Si rende esplicito cosa è stato deciso e perché. Si misura dove serve. Si corregge solo ciò che i dati giustificano — e mentre lo facciamo, i criteri passano al team.
Si osserva
Entriamo nella base esistente: modello, ciclo di vita del DbContext, transazioni, concorrenza, il SQL che Entity Framework genera davvero.
Si rende esplicito
Mettiamo nero su bianco vincoli e decisioni architetturali, distinguendo ciò che regge da ciò che va rivisto. Niente resta implicito.
Si misura
Sui percorsi critici — sincronizzazione delle quattro entità, letture sotto carico — guardiamo i numeri, non le impressioni.
Si corregge il giusto
Entity Framework dove è la scelta corretta; Dapper o accesso diretto solo dove il carico lo richiede. La soluzione più semplice che regge.
Si trasferisce
Ogni decisione diventa un criterio che il team può riusare da solo. L'obiettivo è la vostra autonomia, non la nostra presenza.
Si documenta
Le scelte vengono motivate e tracciate, pronte da portare in una riunione o in un fascicolo tecnico.
Non consulenza che svanisce. Un documento che il Direttore Tecnico può portare in riunione.
- Assessment dell'architettura dati
Lo stato reale della base comune alle macchine automatiche e non automatiche.
- Mappa dei flussi e dei confini di responsabilità
Chi scrive, chi legge, dove passano i dati tra PC, PLC, bilancia e stampante.
- Revisione del modello e del ciclo di vita del DbContext
Il punto dove nascono la maggior parte dei problemi di concorrenza.
- Analisi di concorrenza e gestione dei conflitti
Più terminali sullo stesso dato: chi arriva prima, cosa succede, come si risolve.
- Revisione delle query e del SQL generato
Dal LINQ alla query reale, con gli strumenti per vederlo e ottimizzarlo.
- Criteri: dove Entity Framework, dove valutare alternative
Una regola difendibile, non una preferenza personale.
- Registro delle decisioni architetturali
Ogni scelta motivata e datata: la responsabilità diventa tracciabile.
- Matrice dei rischi prioritizzati + piano d'azione
Cosa affrontare prima, cosa può aspettare, con quali tempi.
L'AI accelera la bozza. La revisione firma la decisione.
Usate Codex e strumenti simili come si usava una volta la ricerca: per andare più veloci. Il rischio non è l'AI. È che una decisione architetturale suggerita da un modello entri in un sistema omologato senza che qualcuno con esperienza e contesto l'abbia rivista.
Su un software che deve durare 15–20 anni, quello che conta è la revisione, la tracciabilità e la responsabilità di ogni scelta. Il percorso vi dà un punto di validazione esterno: le decisioni le prendete voi, ma non le prendete da soli.
Ventisei anni sullo stesso tipo di problema: dati critici che devono durare.
- Ventisei anni su .NET e architetture software; tre software house fondate, l'ultima un gestionale per avvocati sul mercato da quindici anni.
- Esperienza diretta su prodotti mantenuti per molti anni, dove ricostruire eventi, tracciabilità e integrità del dato non sono opzionali.
- Quindici mesi su una bilancia usata da 15.000 ricercatori in ambito farmaceutico, con certificazione FDA e ambienti separati fino alla produzione.
- Si lavora sul codice reale, non su slide: il principio è la soluzione più semplice che soddisfa i vincoli — perché quel codice lo dovrete mantenere ogni giorno.
- Il percorso lo seguo personalmente: in una realtà come la vostra è troppo delicato per delegarlo.
Per Coop Bilanciai il percorso corretto è di sei mesi.
Non perché sei sia una via di mezzo. Perché tre mesi coprono la partenza e vi lasciano soli proprio quando emergono migrazioni reali, concorrenza e carico. Sei mesi accompagnano il progetto nel tratto in cui i problemi diventano veri — con team nuovo a Entity Framework e un sistema destinato a vent'anni, è il punto di equilibrio tra protezione e investimento.
Comprensione e validazione
Si legge la base esistente e si conferma o si corregge la direzione.
Applicazione e prime migrazioni
Le decisioni entrano nel codice; prime revisioni sui casi reali.
Problemi emergenti
Concorrenza, query e carico: quelli che oggi non si possono simulare.
Consolidamento e autonomia
Documentazione, criteri riusabili, team indipendente.
Copertura iniziale ridotta
Valida la base e apre le prime decisioni, ma si ferma prima delle fasi in cui emergono i problemi veri.
Copertura dell'intero rollout
Disponibile se volete validazione esterna lungo tutto il rollout, non solo all'inizio. Non necessaria come primo passo.
Modalità costruita sulla vostra: uno sprint iniziale, poi sessioni remote da due ore ogni due settimane. Senza fermare l'operatività, senza corsi da otto ore che non hanno più senso.
Non va confrontato con un corso. Va confrontato con il costo di rifare.
Il metro non è la formazione. È cosa costa scoprire tardi una decisione sbagliata su un sistema omologato che deve durare vent'anni. Il calcolo lo fate voi — con i vostri numeri, che conoscete meglio di chiunque.
Il prossimo passo è concreto
Definiamo lo sprint iniziale.Non "ci pensiamo".
Una sessione operativa per fissare perimetro, accessi e primo sprint sulla vostra architettura. Gli argomenti sono già chiari: resta da decidere modalità e durata.