{"id":658,"date":"2016-04-02T22:55:51","date_gmt":"2016-04-02T20:55:51","guid":{"rendered":"http:\/\/www.ilbytecidio.it\/?p=658"},"modified":"2016-04-02T22:55:51","modified_gmt":"2016-04-02T20:55:51","slug":"alla-scoperta-di-mvc","status":"publish","type":"post","link":"https:\/\/www.ilbytecidio.it\/?p=658","title":{"rendered":"Alla scoperta di MVC"},"content":{"rendered":"

Se un programmatore prendesse la briga di scrivere un libro sugli ultimi dieci anni della propria es\"model\"perienza, verrebbe fuori senza dubbio un mattone dalla notevole mole. In questi anni abbiamo visto andare, passare e tornare di moda tanti concetti e non si contano pi\u00f9 le volte che termini come “Applicazione”, “Web”, “Server” e molte altre all’apparenza banali si sono intrecciate. Dopo anni di sviluppo le costanti sono almeno due: il codice<\/strong> tende a crescere e molto spesso (non sempre, ma molto spesso) \u00e8 scritto malissimo<\/strong>!<\/p>\n

<\/p>\n

Se dieci anni fa gi\u00e0 arricciavamo il naso al pensiero di scrivere una pagina PHP che mischiasse tutto, dalla lettura dal database al codice HTML\/CSS o di piazzare la logica di un’applicazione Java (o C++ o Visual Basic, ecc) nei gestori dei bottoni, oggi queste pratiche sono inaccettabili probabilmente anche per gli studenti d’informatica alle prime armi. Eppure ci troveremo spesso a fare i conti con pratiche di programmazione orribili, spesso per pura pigrizia o forse paura di alcuni di imparare qualcosa di meglio. In questo articolo user\u00f2 la terminologia della programmazione a oggetti, ma gli stessi concetti possono essere applicati anche alla programmazione procedurale.<\/p>\n

Il primo passo per chi vuole abituarsi a scrivere programmi migliori \u00e8 sempre lo stesso: separare l’interfaccia dall’implementazione<\/strong>: nella forma pi\u00f9 semplice, si scrive una o pi\u00f9 classi che definiscono il comportamento dell’applicazione e un’interfaccia che consenta l’interazione dell’utente con essa. Facile a dirsi, eppure a giudicare da certi ammassi informi di codice che si vedono in giro, non lo \u00e8 nella pratica e, soprattutto, non sempre basta<\/strong>!<\/p>\n

La forma da dare al proprio codice \u00e8 una scelta importante da farsi ancor prima di scrivere una sola istruzione e dipende da quali sono le esigenze. La pena per un approccio alla leggera \u00e8 ritrovarsi faccia a faccia con la difficolt\u00e0 di aggiungere nuove funzionalit\u00e0 al nostro programma, che nei casi estremi sfocia in un copia-incolla di funzioni difficilmente riutilizzabili o, peggio, alla condizione nota come “Spaghetti code”, in cui il programma diventa di fatto illeggibile e non pi\u00f9 mantenibile. Un codice ben scritto ha almeno le seguenti due caratteristiche:<\/p>\n

    \n
  1. Separazione dei concetti.<\/strong>
    \nAvete mai aperto un computer? Noterete senza dubbio che l’alimentatore non scrive dati sull’hard disk e non riceve immagini da Internet. Allo stesso modo, una classe che si occupa di comunicare con un server non \u00e8 probabilmente una buona candidata al compito di generare immagini. Perch\u00e9? Perch\u00e9 sono due compiti diversi ed \u00e8 bene che se ne occupino moduli diversi.<\/li>\n
  2. Astrazione<\/strong>.
    \nGuardando ancora dentro il nostro PC faremo la sensazionale scoperta che disco fisso e lettore CD\/DVD sono collegati alla scheda madre con due cavi uguali. La ragione \u00e8 che la loro interfaccia \u00e8 astratta. Questo permette al costruttore di progettare moduli che comunichino fra loro senza curarsi troppo di come sono fatti dentro o, in altre parole, della loro implementazione. Pi\u00f9 volte possiamo riutilizzare un pezzo di codice, meno ne dovremo scrivere, il che significa meno bug, manutenzione pi\u00f9 semplice e facilit\u00e0 di comprensione dei sorgenti, anche per noi stessi quando li rileggeremo dopo mesi.<\/li>\n<\/ol>\n

    \u00c8 tutto? Neanche per sogno, vi basti pensare che persino l’eccesso di astrazione pu\u00f2 rendere il vostro programma illeggibile, ma andare pi\u00f9 a fondo di cos\u00ec va oltre gli scopi di questo articolo. Agli interessati consiglio di dare uno sguardo al catalogo degli anti-pattern<\/a>, ai vari tipi di complessit\u00e0 del software (computazione, ciclomatica, ecc) e naturalmente ai vari design pattern.<\/p>\n

    Uno di questi ultimi \u00e8 per l’appunto MVC (Modello-Vista-Controllo, anche noto come Model-View-Controller). Si tratta di un pattern architetturale, forse il pi\u00f9 noto oggigiorno, che prevede la divisione dell’applicazione in tre componenti fondamentali: Modelli, Viste e Controllori. Scopriamo nel dettaglio di cosa si occupano queste componenti:<\/p>\n

      \n
    1. Modello<\/strong>
      \nIl modello (o entit\u00e0), \u00e8 il mattone fondamentale della nostra applicazione, che ne contiene i dati e la logica fondamentale. Se scriviamo un’applicazione per la gestione di una biblioteca, le entit\u00e0 saranno ovviamente i libri, gli iscritti ed altre, a seconda dei casi. Un modello meno intuitivo che potrebbe esserci utile nella scrittura di quest’ipotetica applicazione \u00e8 il prestito, che oltre al codice del libro e dell’iscritto conterr\u00e0 la data, la durata e, se pensiamo ad un esempio di logica ad esso associata, un calcolo di un’eventuale penale da pagare in caso di ritardo nella restituzione o di danneggiamento.<\/li>\n
    2. Vista<\/strong>
      \nIl compito principale di una vista \u00e8 consentire all’utente dell’applicazione l’interazione con i modelli, qualunque sia il metodo da noi utilizzato per memorizzarne i dati. La vista presenta dunque i dati del modello, si evolve con esso (nei casi ideali) e ne permette eventualmente la modifica. Si noti come il concetto di “Vista” sia astratto e vagamente discriminatorio. Perch\u00e9 il concetto sia pi\u00f9 chiaro, credo sarebbe opportuno sostituire il termine con “Presentazione”. In un dispositivo con soli comandi vocali per esempio non possiamo parlare di vista, ma la funzione di questo componente resta la medesima.<\/li>\n
    3. Controllore<\/strong>
      \nIl controllore riceve i comandi dall’utente e manipola i modelli, modificando di conseguenza la vista. Nella maggior parte delle implementazioni web lato-server di MVC, il controllore si occupa direttamente di generare la vista, passando i dati a un gestore di “template”, come Twig. Da un lato, con questo approccio il controllore riceve i comandi dall’utente (di cui il pi\u00f9 semplice sar\u00e0 la richiesta GET del protocollo HTTP) come dovrebbe, ma dall’altro ci\u00f2 non applica rigorosamente le specifiche. Tuttavia \u00e8 semplice e non vanifica lo scopo principale, quello di una netta separazione dei compiti, cos\u00ec possiamo chiudere un occhio!<\/li>\n<\/ol>\n

      MVC ci aiuta dunque nella prima delle buone caratteristiche del codice che ho precedentemente elencato: la separazione dei concetti. Sfortunatamente, la seconda dipende essenzialmente dal buon uso che faremo di questa separazione. Alcune librerie possono venire in nostro aiuto forzandoci a scrivere il programma in una certa maniera e fornendoci strumenti riutilizzabili per evitarci parte del lavoro sporco ma, ancora, farne buon uso dipender\u00e0 da noi!<\/p>\n

      \u00c8 tutto ora? Non proprio. MVC \u00e8 una specifica, ma la particolare implementazione differisce considerevolmente a seconda della nostra creativit\u00e0, del linguaggio, dell’ambiente di sviluppo, delle librerie e dell’eventuale framework che utilizziamo. L’abbiamo gi\u00e0 visto nella spiegazione del controllore. Un approccio decisamente accademico vuole che la vista sia generata da un solo modello, ma questo \u00e8 decisamente insolito. Immaginiamo per esempio che l’interfaccia della nostra ormai realistica applicazione per la biblioteca includa statistiche sui prestiti dei libri e degli iscritti a ogni schermata. Questo implica l’uso di vari modelli e ci\u00f2 causa non poche crisi esistenziali ai neofiti di MVC. Per la cronaca, molti alleviano il proprio senso di colpa introducendo il concetto di “vista parziale”, del quale non mi occuper\u00f2 qui. Inoltre non tutte le parti del nostro programma sono necessariamente modelli, viste o controllori, specialmente se il nostro programma \u00e8 molto complesso e ad un certo punto sentiamo la necessit\u00e0 di spostare il nostro codice dai modelli per evitare che questo li faccia crescere a dismisura (in gergo si parla di “modelli grassi”) e che divenga difficilmente riutilizzabile.<\/p>\n

      In effetti da specifiche cos\u00ec semplici nasce un mondo di ricerche di soluzioni, decine di approcci diversi e molte discussioni. Torner\u00f2 senza dubbio ad occuparmi dell’argomento. Quando ho iniziato a scrivere quest’articolo ho iniziato a preparare anche un esempio didattico, ma come accade spesso, mi sono lasciato prendere la mano ed esso si \u00e8 evoluto in un vero e proprio framework PHP che sto utilizzando per siti web esistenti e che \u00e8 divenuto il banco di prova per alcune delle mie idee. Anch’esso sar\u00e0 pubblicato ed illustrato a tempo debito. Per il momento, spero che questa modesta spiegazione sia chiara ed utile.<\/p>\n","protected":false},"excerpt":{"rendered":"

      Se un programmatore prendesse la briga di scrivere un libro sugli ultimi dieci anni della propria esperienza, verrebbe fuori senza dubbio un mattone dalla notevole mole. In questi anni abbiamo visto andare, passare e tornare di moda tanti concetti e … Continua a leggere→<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[15],"tags":[],"class_list":["post-658","post","type-post","status-publish","format-standard","hentry","category-programmazione"],"views":138,"_links":{"self":[{"href":"https:\/\/www.ilbytecidio.it\/index.php?rest_route=\/wp\/v2\/posts\/658","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.ilbytecidio.it\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.ilbytecidio.it\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.ilbytecidio.it\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.ilbytecidio.it\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=658"}],"version-history":[{"count":2,"href":"https:\/\/www.ilbytecidio.it\/index.php?rest_route=\/wp\/v2\/posts\/658\/revisions"}],"predecessor-version":[{"id":667,"href":"https:\/\/www.ilbytecidio.it\/index.php?rest_route=\/wp\/v2\/posts\/658\/revisions\/667"}],"wp:attachment":[{"href":"https:\/\/www.ilbytecidio.it\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=658"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.ilbytecidio.it\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=658"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.ilbytecidio.it\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=658"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}