‫Istruttore: Fino a
‫questo punto, abbiamo appena scritto il nostro
‫codice senza pensare molto all'architettura dell'applicazione.
‫Non era molto importante fino ad ora,
‫ma ora che la nostra app sta davvero iniziando a
‫crescere, dobbiamo iniziare
‫a preoccuparci del modo in cui progettiamo o dell'architettura del codice.
‫E questa lezione sarà solo una breve
‫introduzione all'architettura di back-end.
‫A partire dall'architettura MVC.
‫Quindi, in questo
‫progetto, utilizzeremo un'architettura ampiamente utilizzata
‫e ben nota chiamata modello, vista,
‫controller o MVC in breve.
‫E ci
‫sono diversi modi di implementare l'architettura MVC,
‫alcuni più complessi di
‫altri, ma qui
‫lo implementeremo in modo molto semplice.
‫Volevo solo farti sapere
‫che se cerchi MVC su
‫Google, lo troverai implementato in modi diversi.
‫Ok, comunque, in questa architettura, il livello del
‫modello riguarda tutto ciò che
‫riguarda i dati delle applicazioni e la
‫logica di business.
‫E impareremo cosa significa la logica aziendale
‫nella prossima diapositiva.
‫Successivamente, abbiamo il livello del controller
‫e la funzione dei
‫controller è gestire la richiesta dell'applicazione,
‫interagire con
‫i modelli e inviare risposte al client.
‫E tutto ciò si chiama logica dell'applicazione.
‫Infine, il livello di visualizzazione è
‫necessario se abbiamo un'interfaccia grafica nella nostra app.
‫O in altre parole, se stiamo
‫costruendo un sito Web renderizzato lato server,
‫come abbiamo detto prima.
‫In questo caso, il livello di visualizzazione è
‫costituito sostanzialmente dai modelli utilizzati
‫per generare la visualizzazione, quindi il sito Web che invieremo al cliente.
‫E questa è la logica di presentazione.
‫Per ora, stiamo solo creando un'API,
‫quindi non siamo ancora preoccupati per le visualizzazioni.
‫Questo è per un po' più avanti nel corso.
‫Quindi, l'utilizzo di un modello o di un'architettura come questa
‫ci consente di scrivere un'applicazione più modulare, che
‫sarà molto più facile da mantenere in
‫scala, se necessario.
‫E potremmo andare ancora
‫oltre, e aggiungere più livelli di astrazione qui.
‫Ma in questo tipo di applicazione più
‫piccola, l'architettura MVC è più che sufficiente per le nostre esigenze.
‫Ora, tutto questo può sembrare
‫un po' astratto, quindi diamo un'occhiata a MVC nel contesto
‫della nostra app e al ciclo richiesta-risposta.
‫Quindi, come sempre, tutto inizia con una richiesta.
‫Quella richiesta colpirà uno dei nostri router,
‫perché ricorda, abbiamo più router.
‫Fondamentalmente, uno per
‫ogni risorsa, come tour, utenti, eccetera.
‫Ora l'obiettivo del router è delegare la richiesta
‫alla corretta funzione del
‫gestore, che sarà in uno dei controller.
‫E ancora, ci sarà un
‫controller per ciascuna delle
‫nostre risorse, per mantenere queste diverse parti dell'app ben separate.
‫Quindi, a seconda della richiesta in arrivo,
‫il controller potrebbe dover interagire con
‫uno dei modelli, ad
‫esempio per
‫recuperare un determinato documento dal database
‫o per crearne uno nuovo.
‫Ancora una volta, c'è un file modello per ogni risorsa.
‫Dopo aver ottenuto i dati
‫dal modello, il controller potrebbe essere pronto a
‫inviare una risposta al client, ad esempio, contenente quei dati.
‫Ora, nel caso in cui desideriamo effettivamente eseguire il rendering di un
‫sito Web, è necessario un ulteriore passaggio.
‫In questo caso, dopo aver ottenuto i dati
‫dal modello, il controller
‫selezionerà uno dei modelli di visualizzazione e vi inserirà i dati.
‫Il sito Web reso verrà quindi
‫restituito come risposta.
‫Nel livello di visualizzazione di un'app Express
‫di solito è presente un modello di visualizzazione per ogni pagina.
‫Come una pagina di panoramica del
‫tour, una pagina dei dettagli del tour o una pagina di accesso.
‫Nell'esempio della nostra ultima app ovviamente.
‫Quindi, questa è un'ampia panoramica dell'architettura che
‫implementeremo in questo progetto.
‫Ora, per finire, vorrei entrare
‫un po' più in dettaglio sul modello e sul controller.
‫Quindi, uno dei grandi obiettivi di MVC
‫è separare la
‫logica aziendale dalla logica dell'applicazione.
‫Sentirai parlare di questi tipi di logica tutto il
‫tempo quando navighi su Stack
‫Overflow o su un sito simile.
‫Ma cosa sono in realtà questi tipi di logica?
‫Bene, la differenza è un po' supponente, ma questa
‫è la mia opinione su di
‫essa: quindi, la logica dell'applicazione è tutto il
‫codice che si occupa
‫solo dell'implementazione dell'applicazione e non
‫del problema aziendale sottostante che
‫stiamo effettivamente cercando di risolvere con l'applicazione .
‫Come mostrare e vendere
‫tour, gestire le scorte in un
‫supermercato o organizzare una biblioteca, per esempio.
‫Quindi, ancora una volta, la
‫logica dell'applicazione è la logica che fa funzionare effettivamente l'app.
‫Ad esempio, gran parte della logica dell'applicazione in Express
‫riguarda la gestione di richieste e risposte.
‫Quindi, in un certo senso, possiamo
‫anche dire che la logica dell'applicazione riguarda più cose tecniche.
‫Inoltre, se abbiamo viste nella nostra app, la
‫logica dell'applicazione funge da
‫ponte tra i livelli di modello e vista in
‫modo da non mescolare mai la
‫logica aziendale con la logica di presentazione.
‫Tutto ok?
‫Ora, riguardo alla logica
‫aziendale, è tutto il codice che risolve effettivamente il problema
‫aziendale che abbiamo deciso di risolvere.
‫Diciamo ancora, che il nostro obiettivo è mostrare i tour ai
‫clienti e poi venderli.
‫E il codice direttamente correlato alle regole aziendali,
‫al funzionamento dell'azienda
‫e alle esigenze aziendali, è la logica aziendale.
‫Ora, se questo suona ancora un po' troppo
‫filosofico, alcuni esempi nel contesto della nostra ultima app
‫stanno creando nuovi tour nel database dell'app, controllando se
‫la password di un utente è corretta quando accede, convalidando i
‫dati di input dell'utente o
‫assicurando che solo gli utenti chi ha acquistato un determinato
‫tour può recensirlo.
‫Quindi tutta questa roba riguarda il business stesso, e
‫quindi fa parte della logica del business.
‫Ora, dobbiamo tenere presente
‫che la logica dell'applicazione e la
‫logica aziendale sono quasi impossibili da separare completamente e
‫quindi a volte si sovrappongono.
‫Ma dovremmo fare del
‫nostro meglio per mantenere la logica applicativa nei
‫nostri controller e la logica aziendale nei nostri modelli.
‫E c'è anche questa filosofia
‫dei modelli grassi, dei controller
‫sottili, che dice
‫che dovremmo scaricare quanta più logica possibile nei
‫modelli, per mantenere i controller il più semplici e snelli possibile.
‫Quindi un modello grasso avrà tutta la logica di business
‫che possiamo scaricare su di
‫esso, e un controller sottile avrà meno logica possibile, in
‫modo che il controller
‫sia davvero principalmente per gestire le richieste e le
‫risposte dell'applicazione.
‫Bene?
‫Quindi, ora tieni a mente tutto questo
‫mentre procediamo e avanziamo nella creazione delle nostre applicazioni.