Ciao, e benvenuto nella terza puntata della cinquantasettesima stagione. Oggi scopriamo che i mappatori non sono tutti uguali: si dividono in due grandi scuole di pensiero, due filosofie diverse su come un oggetto debba rapportarsi al database. Capire questa divisione ti aiuta a orientarti tra i tanti strumenti che incontrerai. Oggi parliamo delle due grandi scuole: salvarsi da soli o con un aiutante.
Partiamo dalla prima scuola, perché è la più immediata. La prima filosofia dice: l'oggetto sa badare a se stesso. In questo mondo, il tuo oggetto utente non è solo un contenitore di dati: sa anche come salvarsi, come aggiornarsi, come cancellarsi. Gli dici, in sostanza, salvati, e lui va nel database e si scrive da solo. È diretto, immediato, si impara in cinque minuti. L'oggetto e la sua vita nel database sono un tutt'uno. Questa scuola è amatissima in molti framework moderni, proprio perché è così rapida da usare: scrivi pochissimo e ottieni subito il risultato.
Voglio dirti il prezzo di questa comodità, perché c'è. Il rovescio della medaglia è che l'oggetto porta con sé una doppia responsabilità. Da una parte rappresenta un concetto del tuo dominio, un utente, un ordine. Dall'altra sa parlare col database. Queste due cose sono mischiate nello stesso oggetto, saldate insieme. Finché l'applicazione è semplice, è comodissimo. Ma quando la logica cresce, quel mischiare la faccenda del dominio con la faccenda del database può diventare ingombrante, perché l'oggetto non può più esistere senza il database a cui è incollato.
Voglio darti la seconda scuola, perché sceglie l'opposto. La seconda filosofia dice: l'oggetto resti puro, ci pensa un aiutante. Qui il tuo oggetto utente è ignorante del database. Sa solo rappresentare un utente, con le sue regole, e basta. Non sa salvarsi, e va benissimo così. Della persistenza si occupa un componente separato, un aiutante specializzato, che sa come prendere quell'oggetto puro e riporlo nel database, e come ricostruirlo quando serve. L'oggetto vive per conto suo, l'aiutante fa il lavoro sporco. È più cerimonioso, richiede un po' più di impalcatura, ma tiene le due responsabilità ben separate.
Voglio darti l'immagine che rende chiara questa idea, perché la fissa. Pensa a due professionisti. Il primo si gestisce da solo tutte le pratiche burocratiche: fatture, moduli, archiviazione. È autonomo, non dipende da nessuno, e per uno studio piccolo è perfetto. Il secondo si concentra solo sul suo mestiere, e ha un assistente che si occupa di tutta la burocrazia. Ha bisogno di quell'assistente, è vero, ma può dedicarsi al suo lavoro senza distrazioni, e quando lo studio cresce questa separazione ripaga. Nessuno dei due ha ragione in assoluto: dipende dalla dimensione e dalla complessità di ciò che stai costruendo. Il professionista autonomo, se lo studio diventa grande, finisce per passare metà giornata sulla burocrazia invece che sul suo mestiere. Ma imporre un assistente a chi lavora da solo su pratiche minime è solo un costo inutile, una cerimonia che non serve a nessuno.
Voglio aiutarti a scegliere, perché è una domanda pratica. Come orientarsi, allora? La regola pratica è più o meno questa. Se stai costruendo un'applicazione dove il grosso del lavoro è gestire dati in modo semplice, creare, leggere, aggiornare, cancellare, la prima scuola, quella dell'oggetto che si salva da solo, ti farà volare: meno cerimonie, più velocità. Se invece stai costruendo un sistema con una logica di dominio ricca e complessa, che vuoi mantenere pulita e indipendente dai dettagli di come i dati vengono conservati, la seconda scuola, quella dell'aiutante separato, ti ripagherà la maggiore fatica iniziale con un codice più ordinato nel tempo. Molti strumenti moderni, per non scontentare nessuno, offrono entrambi gli stili, e lasciano a te la decisione. Vale la pena sapere, quando scegli o quando erediti uno strumento, quale delle due filosofie stai abbracciando: perché quella scelta plasmerà, in silenzio, come è fatto tutto il tuo codice attorno ai dati.
Voglio darti la lezione generale, perché è un principio di progettazione. La lezione è che dietro ogni strumento comodo c'è una scelta su dove mettere le responsabilità, e quella scelta ha conseguenze. Mescolare le cose rende tutto più rapido all'inizio e più aggrovigliato dopo. Separarle costa di più all'inizio e ripaga quando la complessità cresce. Non è una questione di moda o di gusto: è un compromesso classico tra rapidità immediata e ordine di lungo periodo. Riconoscere quale delle due ti serve, per il progetto che hai davanti, è già metà del mestiere.
Per oggi ci fermiamo qui. Abbiamo visto le due grandi scuole dei mappatori. La prima: l'oggetto sa salvarsi da solo, gli dici salvati e lui si scrive nel database. Immediata, rapidissima, ma mescola il concetto di dominio con il mestiere di parlare al database. La seconda: l'oggetto resta puro e ignorante, e un aiutante separato si occupa di riporlo e ricostruirlo. Più cerimoniosa, ma tiene le responsabilità separate. Come un professionista che fa da sé tutta la burocrazia contro uno che ha un assistente dedicato. La scelta dipende dalla complessità: rapidità immediata contro ordine di lungo periodo. Nella prossima puntata: la sessione invisibile, come il mappatore tiene il conto. Nelle note trovi qualche spunto. Se ti è utile, condividila. Grazie per l'ascolto, e ci sentiamo alla prossima.