Pattern MVC

14 Maggio 2020 0 di danilo

Pattern mvc, comodo e pratico per creare delle applicazioni web da urlo e facili da gestire

Tutto ciò che è contenuto in questo articolo è frutto della mia esperienza e della mia opinione personale. E’ una spiegazione generale. Per approfondire, su internet ci sono tante guide molto più tecniche e dettagliate. Questo articolo serve per capire gli argomenti che tratteremo nelle prossime guide

Buongiorno a tutti “Ignoranti” (me compreso ovviamente),

Oggi, vedremo quello che si definisce pattern MVC. Prima di addentrarci nel complesso, iniziamo a definire cosa si intende per pattern.

Pattern

In informatica, per pattern si intende uno schema progettuale atto a risolvere problemi ricorrenti, in parole povere è una sorta di schema che definisce delle regole generali per lo sviluppo, esistono diversi tipi di pattern, non entro nel dettaglio, per avere più informazioni su wikipedia, c’è tutto https://it.wikipedia.org/wiki/Design_pattern .

Pattern MVC – Questo grande sconosciuto

Si sente parlare di MVC ma che cos’è? Partiamo con il dire che MVC sta per Model View Controller. Quindi, modello, vista, controllore.

MVC è semplicemente un modo per creare applicazioni web utilizzando diversi livelli che sono appunto il model, le view e i controller.

Molti framework utilizzano questo “paradigma” , oggi però non ci soffermeremo sui linguaggi di programmazione ma solo sulla teoria.

Come funziona ?

Il suo funzionamento può sembrare complesso ma in realtà è molto semplice. Si suddivide il codice in vari blocchi che hanno delle funzioni ben precise. Andiamo a definire ogni singola parte.

Questo è lo schema del pattern MVC, proviamo a capirlo. Partiamo dal basso.

La prima cosa che vediamo in un’applicazione web è l’intefaccia utente, quindi il sito vero e proprio, che è la VIEW, quindi la vista, la risultante di tutto quello che vedete sopra.

Come si compone la vista?

Per ottenere questo risultato, si passa per varie operazioni, qui entrano in gioco Model e Controller. Seguendo l’immagine sopra, si può intendere, che la vista chiami il controller, il controller chiama il model e il model richiama la vista. Detto così è un po’ complicato e complesso da capire.

In pratica funziona in modo un po’ diverso.

La vista in realtà viene generata dal Controller, che generalmente è una classe che contiene una serie di metodi. Se non sapete cos’è una classe, a breve pubblicherò un articolo che spiega la programmazione ad oggetti. Limitiamoci a dire che è un contenitore che contiene varie funzioni. Cosa fanno queste funzioni? Queste funzioni vanno ad interrogare la base dati attraverso il model e restituiscono vari valori che vengono passati alla vista.

Facciamo un esempio.

Ho un sito web che deve visualizzare l’elenco di tutti gli utenti registrati.

  • L’utente clicca sul bottone “visualizza utenti”
  • La vista, manda questa richiesta al controller.
  • Il controller, normalizza e controlla la richiesta mandata dalla vista e in caso di errori li restituisce alla vista mostrandoli all’utente, diversamente li manda al model
  • Il model, prende la richiesta, la elabora e restituisce l’elenco degli utenti al controller.
  • Il controller richiama un’altra vista (oppure la stessa di prima) passandogli quello che il model gli ha restituito.
  • La vista viene generata mostrando il contenuto richiesto.

In un ambito non MVC le operazioni sarebbero queste

  • L’utente clicca sul bottone “visualizza utenti”
  • Un’altra pagina web viene richiamata, questa, valida la richiesta, la stessa pagina, apre una connessione alla base dati, iterroga la base dati, converte il risultato e lo restituisce.

La prima differenza che si nota è che nella seconda opzione si hanno meno passaggi mentre la prima è un po’ più articolata. Riporto due esempi di alberature del sito

MVC

  • Models
    • UsersModel
  • Controllers
    • UsersController
  • Views
    • Users
      • Index
      • CreateUser
      • ModifyUser

NON MVC

  • Index
  • Users
  • Functions
    • UsersFunctions

Ho semplificato molto la seconda opzione, però si può notare che nel primo caso l’alberatura è molto più complessa della seconda.

Analizziamo ora gli Url, sempre facendo riferimento all’esempio precedente

MVC

https://applicazioneWeb/Users/index

Non MVC

https://applicazioneWeb/Index?function=GetUser

Facciamo qualche considerazione su questo

Nel caso MVC abbiamo un url del tipo NomeDominio/Controller/Azione/Parametro

Nel secondo caso abbiamo

NomeDominio/PaginaUtilizzata?NomeParametro=Parametro

Ora, ho molto generalizzato, ci sono mille configurazioni possibili.

Che cosa è il Controller?

Come ho anticipato prima, il contoller è un oggetto che contiene sia le funzioni “intermediarie” tra la vista e il model che delle funzioni che restituiscono dei dati non passando per forza dal model. Esempio, un’ applicazione che deve fare in continuazione calcoli con dei numeri passati dall’utente, non per forza deve interrogare il model, avrà nel suo controller una funzione di calcolo che restituirà quei dati. Il controller quindi è il punto nevralgico, in pratica tutto passa da li, ricordate l’esempio di prima? Avrete notato che passo dal controller sia nella richiesta che nella risposta.

Che cosa è il Model?

Bene, qui si apre un mondo. Il model è tutto un elenco di oggeti che rappresenta la nostra base dati. Faccio prima a fare un esempio.

Abbiamo su un database una tabella utenti che conterrà nome, cognome, email . Dobbiamo richiedere queste informazioni. In una situazione normale faremo in questo modo (non prendo in considerazione nessun linguaggio di programmazione ma solo il modo in cui interagiamo) :

ConnessioneDB = connectToDB(Connectionstring)

Query = “SELECT * FROM Users”

ReaderObject = ExecuteQuery(Query)

DataToView = ReaderObject[“nome”] + ” ” + ReaderObject[“cognome”] +ReaderObject[“mail”]

Se questo non lo mettessimo in una funzione, dovremmo riscriverlo tutte le volte che ci serve. Con invece un po’ di lavoro in più alle spalle e con l’utilizzo degli ORM, si può ottenere nel controller questo

Model.Users = GetUsers()

DataToView = Users.Nome + ” ” + Users.Cognome + Users.Mail

Cosa è successo? In sostanza, la funzione GetUsers, ha preso i dati dal Database e li ha messi in un oggetto chiamato Users (che in realtà è il nostro model) che come proprietà ha nome,cognome,mail . Quindi, abbiamo creato un oggetto che ha gli stessi campi della base dati e che conterrà i dati della base dati, la differenza è che per interrogarlo non dobbiamo fare nessuna query ne connessione al db , perchè in questo caso se ne occupa la funzione GetUsers. Ultima cosa ma non meno importante, questo codice, può essere riutilizzato in qualsiasi parte del progetto.

Ricapitolando, il model è un oggetto che rappresenta la base dati e che può essere utilizzato anche per gli inserimenti o per le modifiche, ad Esempio, sempre nel controller potremmo avere

Model.Users = new Users()

Users.Nome = Danilo

Users.Cognome = Garro

Users.Mail = danilo.garro@sviluppoignorante.it

InsertUser(Users)

Cosa ho fatto ? Ho creato un oggetto Users (model), gli ho messo i dati che mi servono e ho chiamato una funzione per inserire quei dati nel Database o comunque nella mia base dati.

Considerazioni Finali

Come considerazioni finali vorrei fare un elenco dei pro e dei contro sul pattern MVC

PRO

  • Facile da gestire e da mantenere, ha un alberatura più complessa però è molto ordinata e si sa sempre quale oggetto si occupa di cosa.
  • Il 90% dei framework è integrato con ORM e TemplateEngine, oggetti che rendono l’esperienza di sviluppo un po’ più semplificata.

Contro

  • Curva di apprendimento maggiore
  • Lo sviluppo di applicazioni è leggermente più lento senza l’utilizzo di framework o altro

In pratica, sviluppare utilizzando il pattern MVC è leggermente più complesso e lento, però il tempo che occupate in precedenza lo recuperate in fase di manutenzione.

Gli esempi che ho fatto presuppongono l’utilizzo di un framework e di un ORM . Riporto di seguito i framework e gli ORM che ho provato e che ho trovato molto validi

Per quanto riguarda i linguaggi Microsoft

ASP.Net MVC con ORM Entity Framework

Per php

Symfony con ORM Doctrine

Laravel con ORM Eloquent

CodeIgniter – non ho mai provato un ORM con codeigniter

Su ogni framework ho messo il link alla sua pagina ufficiale con la documentazione, per quanto riguarda gli ORM e i template engine, normalmente sono inclusi nel framework quindi la documentazione si trova all’interno.

Buono sviluppo a tutti