Corso ASP.NET MVC: cosa imparare e in che ordine per lavorare davvero con ASP.NET Core

Un corso ASP.NET MVC si giudica da una cosa sola: l'ordine in cui ti fa imparare le cose.

Non dalle ore di video, non dall'elenco di tecnologie stampate in copertina.

Il certificato finale, poi, non lo guarda nessuno.

Prendi Davide: tre anni di C#, gestionali desktop e WPF, zero web.

A gennaio decide di imparare ASP.NET MVC, ma un corso non lo sceglie: apre YouTube e mette in coda i tutorial con più visualizzazioni.

Parte dal database, perché i dati gli sembrano la cosa più concreta.

Poi salta al routing, perché un video lo definiva irrinunciabile.

Terzo passaggio: l'autenticazione, perché il tutorial successivo parlava di quella.

Sei mesi dopo ha venti nozioni slegate in testa e nessuna applicazione da aprire davanti a un selezionatore.

Il problema non è Davide.

E non è nemmeno la tecnologia.

Il problema è l'apprendimento a silos: l'ordine caotico dell'autoapprendimento, che ti riempie la testa di pezzi incapaci di collaborare tra loro.

Ogni tutorial funziona da solo.

Nessuno ti dice dove e come va usata la parte che ti ha appena insegnato.

In 27 anni ho costruito sistemi per Il Sole 24 Ore, NATO, FIAT e GSK, e ho visto decine di sviluppatori fermarsi lì.

Quindi ti dico subito la cosa scomoda: la tua disciplina non c'entra niente.

Davide studiava sei sere a settimana.

Studiare tanto nell'ordine sbagliato produce meno di studiare la metà nell'ordine giusto.

In questo articolo ti mostro cosa si impara in un corso ASP.NET MVC e, soprattutto, in che ordine si impara.

Il riferimento è ASP.NET Core MVC su .NET 8 e 9, la piattaforma attuale, non il vecchio framework rimasto indietro di dieci anni.

Alla fine, avrai la roadmap ASP.NET Core 2026 completa: dal pattern MVC fino al rilascio, passando per tutto quello che sta in mezzo.

Poi deciderai tu se farla da solo o con qualcuno che ti corregge lungo la strada.

Perché un corso ASP.NET MVC parte dal pattern e non dal codice

Si parte dal pattern perché è il modello mentale che assegna un posto a ogni cosa che studierai dopo: routing, controller, view, dati, sicurezza.

Senza quel modello ogni argomento resta un'isola, e le isole non fanno un'applicazione.

La tentazione di chi vuole imparare ASP.NET MVC da zero è un'altra, lo so bene: aprire Visual Studio e scrivere subito.

I tutorial assecondano questa fretta, e non per cattiveria: il video che mostra un risultato in dieci minuti trattiene più spettatori di quello che spiega un modello mentale.

Ecco perché l'apprendimento a silos è la norma: nessuno vende il modello mentale, tutti vendono il risultato immediato.

Così il pattern Model-View-Controller finisce nella casella "teoria da saltare per arrivare alla pratica".

Ed è invece l'unico argomento che dà senso a tutti gli altri.

L'idea, spogliata del gergo, è semplice: dividere l'applicazione in tre ruoli, ognuno con il suo compito.

Il Model rappresenta i dati e le regole del tuo dominio, cioè quello di cui l'applicazione parla.

La View è la parte che l'utente vede e con cui interagisce.

Il Controller fa da coordinatore: riceve la richiesta, decide cosa fare, recupera i dati e sceglie quale vista mostrare.

L'applicazione funzionerebbe anche tutta in un file solo.

Il pattern MVC serve a tenerla modificabile mentre cresce, che dal secondo mese in poi è l'unica cosa che conta.

MVC nel contesto di ASP.NET Core

ASP.NET Core MVC è l'implementazione Microsoft di questo pattern, ricostruita da zero per essere veloce e multipiattaforma.

Sotto il pattern lavora una catena di componenti, i middleware, che ogni richiesta attraversa uno dopo l'altro prima di arrivare al controller.

Autenticazione, routing e gestione degli errori vivono lì, in un ordine preciso.

Invertire due righe in quella catena basta a rendere pubblica una pagina che credevi protetta.

Per ora ti basta sapere che esiste: è la strada che ogni richiesta percorre.

Il ciclo di una richiesta, una volta per tutte

Fissa questo flusso, perché è la spina dorsale dell'intera roadmap:

• L'utente chiama un indirizzo e il routing decide quale controller e quale azione devono rispondere;
• Il controller riceve i dati della richiesta già confezionati, fa il suo lavoro e prepara un model; la view prende quel model e genera la pagina HTML che torna al browser.

Tutto qui: ogni argomento che studierai da qui in avanti è un anello di questa catena.

Nel 2024 ho seguito tre sviluppatori di una software house di Varese, fermi da mesi sugli stessi tutorial.

Abbiamo buttato via il loro piano di studio e siamo ripartiti dal ciclo della richiesta, un argomento a settimana.

Dopo dieci settimane, avevano in produzione un gestionale interno: piccolo, ma completo di autenticazione e rilascio.

Nessuno di loro aveva studiato più ore di prima.

Il primo silo è caduto quando hanno capito perché esiste il pattern.

Routing: come ASP.NET decide quale codice eseguire

Il routing è il meccanismo che, dato un indirizzo, sceglie quale controller e quale azione devono rispondere.

Davanti a /prodotti/dettaglio/42 il framework non fa niente di magico: applica regole che hai scritto tu.

I tutorial ASP.NET MVC liquidano queste regole in due minuti, e infatti il routing resta il silo più frainteso.

I modi per scrivere queste regole sono due, e in un progetto reale li incontrerai entrambi nello stesso giorno.

Il primo è uno schema generale valido per tutta l'applicazione, del tipo "nome del controller, poi azione, poi eventuale id".

Il secondo è il routing con attributi: dichiari la rotta direttamente sopra l'azione che deve risponderle, e quella regola vale solo lì.

Le differenze che contano nella pratica stanno tutte qui:

Imparare bene il routing significa anche capire i parametri opzionali, i vincoli sui tipi e i link generati dal framework.

Le rotte hanno un nome, e da quel nome fai costruire i link nelle view invece di scriverli a mano.

Così, quando cambi lo schema degli indirizzi, lo cambi in un punto solo e tutta l'applicazione si aggiorna da sola.

Un vincolo dichiarato nella rotta, per esempio che l'id debba essere un numero, rifiuta da solo gli indirizzi sbagliati.

La richiesta non valida muore lì, prima ancora di toccare il tuo codice.

Il giorno che lo scopri cancelli venti righe di controlli scritti a mano.

Quanto costa ignorare questi due strumenti te lo dico con i numeri, perché li ho misurati su un progetto vero.

Nel 2023 ho revisionato un portale B2B con oltre duecento indirizzi scritti a mano dentro le view.

Il cliente voleva rinominare una sezione: due giorni di ricerca e sostituzione, più i test di regressione.

Con le rotte nominate sarebbe stata una modifica da dieci minuti.

Chi aveva scritto quel codice era bravo quanto te, aveva solo imparato le cose nell'ordine sbagliato.

Perché il routing viene prima dei controller

Da autodidatta il routing si affronta quasi sempre dopo i controller, quando le firme delle azioni sono già scritte male.

Capirlo prima ti fa progettare azioni con parametri sensati, perché sai da dove arrivano i valori.

Senza questa comprensione i parametri sembrano magia, e il model binding che incontrerai tra poco diventa incomprensibile.

È il motivo per cui questa roadmap mette il routing al secondo posto e non al quinto.

Controller e view: il cuore operativo dell'applicazione

Controller e view sono il punto dove la richiesta diventa lavoro svolto e risposta visibile.

Qui l'apprendimento a silos presenta il conto più salato, perché gli errori di struttura che commetti adesso invecchiano malissimo.

Un controller scritto male non si vede alla demo: si vede sei mesi dopo, a ogni singola modifica.

Controller snelli, niente logica di business dentro

L'errore classico di chi arriva qui è riempire i controller di logica: query, calcoli, invio e-mail, tutto dentro l'azione.

La regola giusta è un'altra: il controller coordina, non esegue.

Riceve la richiesta, delega il lavoro a una classe di servizio, riceve il risultato e sceglie la risposta.

Io la chiamo la regola del vigile: dirige il traffico, non guida le auto al posto degli automobilisti.

Un'azione lunga trecento righe funziona benissimo alla demo, e poi ti tiene in ostaggio per i cinque anni successivi.

Le view e i tipi di risultato

Un'azione non restituisce direttamente una pagina: restituisce un risultato, che può essere una view, un reindirizzamento, un JSON o un semplice codice di stato.

Questa piccola astrazione ti permette di cambiare tipo di risposta senza stravolgere la struttura del metodo.

Il caso da imparare subito è il pattern Post-Redirect-Get: dopo un form salvato con successo, fai sempre un reindirizzamento.

Eviti i doppi invii quando l'utente ricarica la pagina, un difetto che in un e-commerce si traduce in ordini duplicati e rimborsi da gestire a mano.

ViewModel: il modello pensato per la view

Il ViewModel è una versione su misura dei tuoi dati: contiene solo i campi che quella view deve mostrare o ricevere.

Passare gli oggetti del database direttamente alle view sembra una scorciatoia e invece è un buco di sicurezza.

Un utente malintenzionato può inviare campi che non erano nel form e sovrascrivere proprietà sensibili: la tecnica ha anche un nome, over-posting.

Il ViewModel chiude il problema alla radice e, in più, rende il codice più chiaro da leggere.

Fermiamoci un attimo, perché questo è il punto in cui l'apprendimento a silos fa più danni.

Routing, controller, view e ViewModel funzionano solo come sistema: studiati separatamente restano trucchi senza contesto.

E leggere non basta.

L'ordine lo mantieni solo se qualcuno lo applica con te, sul tuo codice, mentre lo stai scrivendo.

Nel percorso BestSviluppatori segui esattamente questa roadmap costruendo un'applicazione reale, lezione dopo lezione, con il codice rivisto a ogni passo.

Alla fine, ti resta un'applicazione completa nel portfolio e il metodo per costruirne altre.

L'attestato lo lasciamo a chi ne ha bisogno.

Diventi lo sviluppatore che sa come è fatta un'applicazione intera.

Quello a cui il team affida la funzionalità nuova, invece di darla al solito senior.

Fai i conti dell'alternativa, gli stessi che avrebbe dovuto fare Davide: sei mesi di tutorial in ordine casuale sono sei mesi di carriera ferma.

Il costo di un percorso strutturato si confronta con quello di sei mesi di carriera ferma, non con lo zero apparente dei video gratuiti.

Quando le venti nozioni slegate diventano un'applicazione sola, il sapere smette di essere un elenco di trucchi e diventa un metodo.

Prenota una call gratuita di 30 minuti: guardiamo a che punto della roadmap sei, cosa ti blocca, e il passo successivo da fare.

Razor: scrivere HTML dinamico senza impazzire

Razor è il motore di pagine di ASP.NET Core: mescola HTML e C# nello stesso file, senza troppe cerimonie e senza strumenti da configurare.

Con il simbolo della chiocciola passi dal markup al codice e viceversa: stampi una proprietà, cicli una lista, mostri un blocco solo a certe condizioni.

Chi arriva dal frontend moderno si aspetta una filiera di strumenti da montare per un pomeriggio, e trova un file che funziona e basta.

È uno dei pochi momenti in cui .NET regala una sorpresa piacevole.

La view è anche il punto dove i progetti si sporcano più in fretta.

HTML e logica si mescolano, i file crescono, e a un certo punto nessuno vuole più aprirli.

Ed è per questo che Razor merita una settimana intera della roadmap invece di una lezione di passaggio.

In un progetto assicurativo che ho "ereditato" nel 2022, le view contenevano calcoli di premio duplicati in otto punti diversi.

Portare quei calcoli nelle classi di servizio e ridurre le view a puro markup ha dimezzato i tempi di modifica.

Nessuna riscrittura, solo il pezzo giusto messo al posto giusto.

Layout: la struttura comune delle pagine

Il layout è il vestito comune di tutte le pagine.

Intestazione, menu, piè di pagina e riferimenti a stili e script vivono in un unico file.

Le singole view definiscono solo il contenuto centrale, e la duplicazione della struttura HTML sparisce.

Quando il cliente chiede di spostare una voce di menu, la sposti in un punto e hai finito.

Senza layout la stessa richiesta diventa una caccia in trenta file, con la certezza statistica di dimenticarne uno.

Partial view e view component

Le partial view sono frammenti di pagina riutilizzabili, perfette per blocchi che ricorrono, come la scheda di un prodotto.

I view component fanno un passo in più: hanno una loro logica e sanno recuperare i dati da soli, senza chiederli al controller che li ospita.

Il carrello con il conteggio degli articoli, presente su ogni pagina, è il caso di scuola: nessun controller deve ricordarsi di popolarlo.

La regola per scegliere sta in una riga: se il frammento ha bisogno di dati suoi è un view component, se gli bastano quelli che la pagina ha già è una partial.

Tag helper: HTML che parla C#

I tag helper rendono le view leggibili anche da chi conosce solo HTML.

Sono attributi speciali che legano un campo al model, generano il link giusto o mostrano gli errori del form.

Il tutto senza una riga di JavaScript scritta a mano.

Qui crolla un mito che sento a ogni colloquio: per fare web servirebbe per forza un framework JavaScript.

Con Razor lato server costruisci gestionali, portali e siti completi scrivendo pochissimo codice client.

E quando un pezzo di markup ricorre in dieci punti, lo impacchetti in un tag helper tuo, riutilizzabile ovunque.

Per gran parte delle applicazioni B2B italiane è la scelta più produttiva, non un ripiego.

Poi c'è l'altra metà del mondo: se devi costruire un'interfaccia molto interattiva un framework client serve, e chi ti racconta il contrario ti sta vendendo qualcosa.

Model binding e validazione: collegare i dati dell'utente al codice

Il model binding è il servizio che prende i dati grezzi di una richiesta e li trasforma in oggetti C# pronti all'uso.

Tu dichiari una classe come parametro dell'azione, e il framework la riempie leggendo il form, l'indirizzo e la query string.

È qui che il routing studiato prima ti ripaga: sai da dove arriva ogni valore, quindi sai come dichiararlo.

Senza model binding scriveresti a mano decine di letture dal form, con conversioni e controlli sparsi ovunque.

E quando serve controllo esplicito su da dove arriva un valore, lo dichiari con un attributo e togli ogni ambiguità.

Sbagliare questo anello significa passare i pomeriggi a caccia di valori nulli arrivati chissà da dove, con il debugger aperto e nessuna ipotesi.

Validazione: i dati dell'utente non sono mai affidabili

Ogni form della tua applicazione è una porta aperta sul mondo esterno.

Dietro quella porta ci sono utenti distratti e, ogni tanto, qualcuno che ci prova sul serio.

La regola, quindi, non ammette eccezioni: tutto ciò che arriva dal browser è sospetto finché non lo hai validato.

La validazione si dichiara con attributi appoggiati sulle proprietà: campo obbligatorio, indirizzo e-mail valido, lunghezza massima, intervallo ammesso.

Il framework li valuta durante il binding e ti dice, con una riga di codice, se i dati sono accettabili.

Se non lo sono, ritorni la view con i dati già inseriti e gli errori mostrati accanto ai campi.

L'utente non ricomincia da capo, e non abbandona il form.

Un intero form di contatto si descrive con due attributi: nome obbligatorio con una lunghezza massima, e-mail dal formato valido.

Validazioni personalizzate e regole di dominio

Gli attributi standard coprono i casi comuni, ma il dominio ha sempre regole sue.

Una data di consegna che non può cadere di domenica non si esprime con un attributo di serie.

Un codice fiscale valido, un intervallo di date coerente, uno sconto entro i limiti: casi reali, tutti personalizzati.

Per questi casi scrivi tu la regola, in un attributo tuo o dentro il ViewModel stesso.

La validazione lato browser aggiunge reattività all'interfaccia, ma quella sul server resta l'unica che conta: il browser lo controlla l'utente, il server lo controlli tu.

La regola che ripeto da anni: la validazione racconta le regole del dominio, non i capricci del form.

Entity Framework Core: dare persistenza ai dati

Entity Framework Core è il traduttore tra il tuo codice e il database: tu lavori con classi C#, lui pensa alle tabelle.

Definisci le tue classi, configuri un contesto che le mappa al database, e scrivi le query in LINQ, cioè direttamente in C#.

Un tutorial su Entity Framework Core ti porta alla prima query in dieci minuti.

Quasi nessuno ti spiega perché quella stessa query, sei mesi dopo e con dati veri, mette in ginocchio il server.

Code First e migrazioni

Con l'approccio Code First scrivi prima le classi, e lasci che sia Entity Framework Core a generare lo schema del database.

Ogni evoluzione dello schema passa da una migrazione: un file di codice che descrive il cambiamento e finisce in Git come tutto il resto.

La revisioni insieme alle altre modifiche, e il database smette di essere un artefatto misterioso gestito a mano da qualcuno che non lavora più lì.

In produzione le migrazioni si applicano in modo controllato, mai in automatico al primo avvio dell'applicazione.

Il repository pattern e i servizi

Le query non vanno scritte dentro i controller: vivono in classi di servizio o repository, che il framework inietta dove servono.

Questa separazione tiene il database lontano dalla presentazione e rende la logica testabile in isolamento.

È la regola del vigile vista per i controller, applicata un piano più in basso.

Le insidie da conoscere subito

La più famosa si chiama query N+1, e l'idea è questa.

Chiedi cento ordini, e il codice esegue di nascosto cento query in più per recuperare i clienti.

L'applicazione è corretta, i dati sono giusti, e il database muore sotto un carico che non doveva esistere.

Un gestionale logistico che ho analizzato nel 2023 impiegava quaranta secondi a caricare duecento spedizioni.

La causa era una N+1 doppia: risolta con due istruzioni, il tempo è sceso sotto il secondo.

Due istruzioni.

Poi ci sono il tracking delle entità e il lazy loading, due comportamenti automatici comodissimi finché non sai che esistono.

La regola pratica: tracking dove modifichi i dati, niente tracking dove li mostri soltanto.

Il promemoria da tenere accanto alla tastiera è questo:

• query N+1: chiedi cento ordini, il database ne paga trecento;
• tracking delle entità: attivo solo dove i dati vengono modificati;
• lazy loading: comodo in sviluppo, imprevedibile sotto carico.

Sono concetti che si imparano solo su dati veri, con il cronometro davanti: su un database da dieci righe la N+1 non si vede, ed è per questo che nei tutorial non compare mai.

I dati adesso ci sono e sopravvivono al riavvio: resta da decidere chi ha il diritto di vederli.

Hai appena letto tre insidie che i tutorial non nominano mai.

Adesso la domanda vera: quante altre ne stai portando dentro il tuo codice senza saperlo?

Chi lavora da solo le scopre in produzione, chi lavora con qualcuno accanto le scopre in revisione.

Cambia tutto, e cambia prima.

Il Corso ASP.NET esiste esattamente per questo.

Nel Corso ASP.NET il tuo codice viene riletto da chi in 27 anni ha costruito centinaia di sistemi: gli errori che invecchiano male te li segna qualcuno, invece di fartelo scoprire da un cliente arrabbiato.

Ogni mese che aspetti è un mese di codice scritto nell'ordine sbagliato, e quel codice poi resta.

ASP.NET Core Identity: autenticare gli utenti in un'app MVC

ASP.NET Core Identity è il sistema integrato per gestire utenti, password, ruoli e login nelle applicazioni MVC.

La prima distinzione da fissare: l'autenticazione risponde a chi sei, l'autorizzazione risponde a cosa puoi fare.

Confonderle è l'errore concettuale più frequente che vedo nelle revisioni di codice sulla sicurezza.

Messe una accanto all'altra, le due responsabilità si distinguono senza sforzo:

Davanti al login la tentazione è sempre la stessa: scriverselo.

Una tabella utenti, un hash, due query.

In realtà un sistema di autenticazione fatto in casa è una collezione di vulnerabilità in attesa che qualcuno le trovi.

E quando qualcuno le trova non lo scopri da un log: lo scopri da una telefonata del cliente.

Identity gestisce la protezione delle password, la conferma via e-mail, il blocco dell'account e l'autenticazione a due fattori, collaudati da anni di produzione.

Qualsiasi tutorial su ASP.NET Core Identity ti mostra la generazione automatica delle pagine in mezz'ora.

Il valore vero è capire il cookie di autenticazione che c'è sotto.

Un corso serio te lo fa aprire con gli strumenti del browser, per vedere cosa contiene, come è firmato e perché non si può falsificare.

In un'app MVC il flusso tipico è questo, form di login più cookie, non i token delle architetture distribuite.

E Identity si configura nei minimi dettagli: requisiti delle password, durata dei cookie, numero di tentativi prima del blocco.

Le pagine generate di login e registrazione le personalizzi come vuoi, senza riscrivere la logica che ci sta sotto.

Autorizzazione: ruoli e policy

L'autorizzazione si dichiara con un attributo sopra il controller o la singola azione: solo chi è autorizzato passa.

Puoi richiedere un ruolo specifico, la via semplice e adatta ai casi lineari.

L'approccio moderno sono le policy: regole con un nome, come RepartoContabilita, che definisci una volta e riusi ovunque.

Sotto ruoli e policy lavorano i claim: coppie chiave-valore che descrivono l'utente autenticato.

Quando la regola cambia, la modifichi in un punto solo invece che in trenta attributi sparsi.

È la differenza tra una richiesta del cliente evasa in mezz'ora e una serata passata a cercare dove hai scritto quel controllo.

Le protezioni che il framework ti dà già

ASP.NET Core MVC include protezioni automatiche che devi conoscere, se non altro per non disattivarle per sbaglio inseguendo un errore.

I form Razor generano da soli i token che bloccano le richieste contraffatte.

Il testo mostrato nelle view viene ripulito per impostazione predefinita, e la maggior parte degli attacchi basati su script muore lì.

I cookie di Identity nascono con le impostazioni sicure già attive.

Utenti autenticati e dati protetti: l'applicazione web è completa.

Costruire API con ASP.NET Core: oltre le pagine web

Un'applicazione moderna quasi sempre espone anche API: per un'app mobile, un frontend JavaScript o un altro sistema aziendale.

Le API vengono quasi sempre vendute come un mondo separato: corsi dedicati, gergo suo e un altro po' di soldi da spendere.

In ASP.NET Core la separazione è artificiale: la piattaforma è identica, cambiano il formato della risposta e chi la consuma.

I controller delle API condividono con quelli web routing, model binding, validazione e iniezione delle dipendenze.

Il model binding, qui, legge il corpo JSON invece dei campi di un form: stesso meccanismo, sorgente diversa.

C'è anche un attributo apposito che attiva i comportamenti da API: per esempio, la validazione fallita risponde da sola con un errore 400.

Per questo la roadmap le mette qui e non prima: impari una volta, riusi due volte.

I principi REST e i codici di stato HTTP

Una buona API usa i verbi HTTP nel modo previsto: GET legge, POST crea, PUT e PATCH aggiornano, DELETE elimina.

Restituisce codici di stato coerenti: 200 per il successo, 201 per la creazione, 400 per input errati, 404 per risorse assenti.

E struttura gli indirizzi attorno alle risorse, non alle azioni: /api/ordini/42, non /api/getOrdine?id=42.

Vale anche per le API la lezione del ViewModel: esponi oggetti di trasporto dedicati, i DTO, mai gli oggetti del database.

Chi consuma la tua API giudica il tuo lavoro dai codici di stato, prima ancora che dai dati.

Un 200 che contiene un messaggio di errore è il modo più rapido per farsi detestare da chi sta dall'altra parte.

Nei colloqui per posizioni web queste domande arrivano sempre, e la roadmap ti ci fa arrivare preparato.

Documentazione e versioning

ASP.NET Core si integra con OpenAPI e genera la documentazione degli endpoint direttamente dal codice.

Chi la usa vede contratti sempre aggiornati, senza che tu mantenga un documento a parte destinato a diventare falso entro due settimane.

Versioning e gestione uniforme degli errori completano il profilo di un'API professionale.

Minimal API: l'alternativa leggera

Le Minimal API definiscono endpoint senza controller, con una sintassi ridotta all'osso.

La regola pratica che uso nei progetti: MVC per applicazioni strutturate, Minimal API per servizi piccoli e focalizzati.

Conoscerle entrambe ti permette di scegliere, invece di subire la scelta fatta da qualcun altro tre anni prima che tu arrivassi.

Il codice adesso fa tutto quello che deve.

Ma come fai a saperlo con certezza?

Testing: la rete di sicurezza che ti fa dormire la notte

Il testing è la parte che i tutorial gratuiti saltano quasi sempre, ed è quella che i team professionali guardano per prima.

Ho fatto colloqui a centinaia di sviluppatori: chi sa impostare un test ragionevole passa davanti a chi elenca dieci framework.

Nei team strutturati una modifica senza test non passa la revisione, e non è pignoleria.

Il codice senza test si rompe in silenzio, e te ne accorgi quando chiama il cliente.

Se guidi una squadra sai già di cosa parlo: la differenza tra una release serena e un venerdì sera in reperibilità sta quasi sempre qui.

Il testing non è quello che fai quando hai finito: è quello che ti permette di finire.

Unit test della logica di business

Se hai seguito la roadmap, i controller sono snelli e la logica vive nei servizi: gli unit test diventano semplici.

Testi le classi di servizio in isolamento con xUnit o NUnit, sostituendo le dipendenze vere con oggetti finti, i mock.

Ogni test segue lo stesso ritmo in tre tempi: prepari i dati, esegui il metodo, verifichi il risultato.

Un test scritto bene documenta il comportamento meglio di qualsiasi commento nel codice, e a differenza del commento non mente mai.

Il prezzo di questa semplicità lo hai già pagato prima, tenendo separate le responsabilità.

Chi ha la logica dentro i controller, a questo punto, deve riscrivere metà applicazione per riuscire a testarla.

Integration test dei controller

Gli integration test verificano il percorso completo di una richiesta: routing, model binding, controller e accesso ai dati.

ASP.NET Core permette di avviare l'intera applicazione in memoria e di farle richieste HTTP reali, dentro i test.

Per il database usi un'istanza dedicata ai test o un provider in memoria, mai i dati veri.

È il test che ti dice se l'applicazione funziona, non solo se i singoli pezzi funzionano.

Quanto testare, davvero

La risposta onesta: meno del cento per cento, più di quello che fai oggi.

Testa la logica di business e i percorsi dove un errore produce danni economici reali.

Un form di contatto che perde un messaggio è un fastidio, un calcolo dell'IVA sbagliato è un contenzioso.

Non sprecare tempo a testare codice banale solo per gonfiare una metrica di copertura, che è il modo più elegante di mentire a sé stessi.

E quando trovi un bug, scrivi prima il test che lo riproduce: è l'unica garanzia che non torni tra sei mesi con un altro nome.

Dal localhost ad Azure App Service: il primo rilascio MVC

Un'applicazione che gira solo sul tuo computer non è un'applicazione: è un esercizio.

Le richieste di aiuto che ricevo si somigliano tutte: l'app funziona in locale e il primo rilascio fa paura.

È normale che ti spaventi.

Fino a quel momento hai avuto un solo utente, sempre disponibile e molto comprensivo: te stesso.

Eppure nei colloqui il rilascio pesa più di quanto pensi.

Chi ha pubblicato almeno una volta parla di configurazione, ambienti e segreti con una concretezza che non si finge, e chi ti ascolta se ne accorge in trenta secondi.

Il primo rilascio ti obbliga a rispondere a domande che in locale non esistono.

Dove sta la password del database, chi legge i log, cosa cambia tra prova e produzione.

Configurazione per ambienti diversi

ASP.NET Core separa le impostazioni per ambiente: un file di configurazione generale, uno per la produzione, più le variabili d'ambiente del server.

Una variabile dedicata decide quale configurazione si carica: Development sul tuo computer, Production sul server.

La regola non negoziabile: le credenziali del database non entrano mai nel codice sorgente.

In Azure le proteggi con Key Vault o con le impostazioni dell'App Service, fuori dal repository.

Una stringa di connessione finita per sbaglio su un repository pubblico è un incidente da cui si esce con una notte di lavoro e una telefonata imbarazzante.

Pubblicare su Azure App Service

Per chi lavora nel mercato .NET italiano, Azure è la destinazione più frequente, e App Service è il punto d'ingresso.

Pubblichi in pochi passaggi da Visual Studio o, meglio ancora, da una pipeline automatica.

Configurare il servizio, collegare un database Azure SQL e gestire le variabili d'ambiente sono competenze che spendi dal primo giorno in un team nuovo.

Dopo la pubblicazione arriva la parte che i tutorial ignorano sistematicamente: leggere i log quando qualcosa non parte.

App Service ti dà log e diagnostica integrata, e il piano gratuito basta per imparare: non hai nemmeno la scusa del budget.

Un dominio, un certificato HTTPS gestito da Azure, un database collegato: la tua prima applicazione pubblica è completa.

E un indirizzo che chiunque può aprire vale più di dieci attestati stampati.

È l'unica riga del tuo curriculum che nessuno può contestarti, perché si verifica in un clic.

È anche il primo momento in cui routing, validazione, Identity e migrazioni lavorano tutti insieme, davanti a utenti che non sei tu.

Container e CI/CD: lo sguardo avanti

Dopo il primo rilascio manuale, la strada naturale è l'automazione: Docker per i container, GitHub Actions o Azure DevOps per la pipeline.

Sono argomenti del capitolo successivo, non di questo.

Chi te li propone adesso ti sta facendo perdere tempo.

Metterli prima delle basi è l'ennesima forma di apprendimento a silos, solo con strumenti più di moda.

Fai il conto onesto.

Sei mesi di tutorial in ordine casuale non sono sei mesi di studio: sono sei mesi di carriera ferma, e non te li restituisce nessuno.

Nel frattempo, qualcuno con meno talento di te ha pubblicato la sua prima applicazione e ha smesso di candidarsi, perché adesso lo cercano.

Il Corso ASP.NET accorcia quella distanza, e la accorcia subito.

Nel Corso ASP.NET percorri la roadmap intera, dal pattern al rilascio, con il codice rivisto a ogni passo: alla fine ti resta un'applicazione completa e il metodo per costruirne altre.

La prima call dura trenta minuti, è gratuita, e se il percorso non ha senso per te, te lo dico io.

La roadmap completa di un corso ASP.NET MVC: l'ordine giusto in una pagina

Eccola, la sequenza intera: quella che smonta l'apprendimento a silos un pezzo alla volta.

Le guide ASP.NET Core per principianti partono quasi sempre dal progetto vuoto: questa roadmap parte dal modello mentale, ed è tutta lì la differenza.

Pattern MVC e ciclo di una richiesta:

• Routing
• Controller e view
• Razor: layout, partial view e tag helper
• Model binding e validazione
• Entity Framework Core e migrazioni
• Autenticazione e autorizzazione con Identity
• API REST e Minimal API
• Testing: unit e integration
• Rilascio su Azure App Service

Il principio che tiene insieme la roadmap è uno solo: impari un pezzo e lo applichi subito a un'applicazione che cresce.

Solo quando il pezzo è montato passi al successivo, perché ogni argomento prepara quello dopo.

Dieci tappe e un'applicazione sola che le attraversa tutte: è la struttura che rende la velocità possibile.

Ogni deviazione dall'ordine ha un costo che paghi più avanti, con gli interessi.

Non ti serve l'ennesimo tutorial ASP.NET MVC: ti serve l'ordine che trasforma dieci argomenti in una sola applicazione.

Razor Pages o MVC: quale imparare prima

La differenza tra Razor Pages e MVC sta nell'organizzazione: pagine autonome, ognuna con il proprio codice, contro controller che coordinano più view.

Razor Pages è più semplice per siti fatti di pagine indipendenti, MVC domina negli annunci di lavoro e nei progetti strutturati.

Il mio consiglio per chi deve scegliere: parti da MVC, perché ti regala l'ottanta per cento di Razor Pages.

Il contrario non è vero, e la roadmap resta identica in entrambi i casi.

Cosa evitare durante il percorso

Tre trappole ricorrenti.

La prima: saltare l'ordine perché un argomento sembra più urgente o più interessante di un altro.

La seconda: fermarsi alla teoria senza completare un progetto, perché i tutorial finiti danno l'illusione del progresso senza produrne nemmeno un grammo.

La terza: investire su ASP.NET MVC 5, la versione legacy, invece che su ASP.NET Core MVC.

Se un corso ASP.NET Core MVC in italiano ti propone ancora .NET Framework, stai guardando un pezzo da museo con il prezzo di un corso.

Un corso di web development .NET serio dichiara la versione su cui lavora, nella prima pagina, senza che tu debba chiederlo.

Perché l'ordine è la differenza tra sapere e saper fare

Ogni mese passato a saltare da un tutorial all'altro è un mese in cui il tuo portfolio resta vuoto, e un portfolio vuoto si paga a ogni colloquio e a ogni rinnovo.

L'ordine giusto, però, non richiede più tempo del disordine.

Richiede solo che qualcuno te lo indichi prima, invece che dopo.

Un tutorial completo su ASP.NET Core ti dà i contenuti.

L'ordine, e qualcuno che rivede il tuo codice, restano scoperti.

Il mercato premia chi fa lavorare insieme gli argomenti dentro un'applicazione che funziona.

Il numero di tecnologie sul curriculum non lo guarda nessuno.

È vecchia di vent'anni ed è ancora l'unica domanda che conta, in un colloquio tecnico.

Ordine e revisione sono le due cose che il percorso BestSviluppatori mette al centro, ed è il motivo per cui funziona.

La revisione del codice la faccio personalmente su ogni progetto: per definizione i posti non possono essere illimitati.

Per lo stesso motivo non è un percorso per tutti e si accede su candidatura: il metodo funziona solo con chi lo applica con costanza.

Se dalla call risulta che non ha senso per te, te lo dico io, senza girarci intorno.

Davide non è diventato più intelligente in quattro mesi.

Ha solo smesso di raccogliere pezzi e ha iniziato a montarli nell'ordine giusto, e oggi ha un'applicazione in produzione che porta il suo nome.

Tu adesso sei esattamente al bivio in cui era lui a gennaio: da una parte altri sei mesi di video, dall'altra il Corso ASP.NET e una sequenza che qualcuno percorre insieme a te.

Tra un anno guarderai indietro a questa sera e saprai quale delle due strade hai preso, perché una lascia un portfolio e l'altra lascia una cronologia di YouTube.

C'è chi colleziona tutorial e c'è chi costruisce qualcosa di intero.

Decidi tu chi vuoi essere.