Perché dovrei usare un modello MVC?

Oggi sembra che tutti quelli che fanno applicazioni web vogliano usare MVC per tutto. Trovo difficile convincermi a usare questo schema, comunque. Capisco l'idea generale è quella di separare la logica del backend dal frontend che rappresenta il programma. In generale, le viste dipendono sempre dal controller in una certa misura, il che finisce a seconda del modello. Non vedo quale vantaggio mi dia l'aggiunta del controller. Ho letto molto clamore su "questo è il modo in cui le applicazioni dovrebbero essere progettate", ma forse non capisco ancora cosa dovrebbe andare dove. Ogni volta che parlo con altri di MVC sembra che ognuno abbia un'idea diversa di ciò che appartiene a quale categoria.

Quindi, perché dovrei usare MVC? Cosa ottengo utilizzando MVC semplicemente separando il frontend dalla logica del backend? (La maggior parte dei "vantaggi" che vedo di questo modello si ottengono solo separando l'interfaccia dall'implementazione e non riescono a spiegare lo scopo di avere un "controller" separato)

Eh. Martin Fowler è d'accordo con la tua confusione su MVC:

Non trovo terribilmente utile pensare a MVC come a uno schema perché contiene alcune idee diverse. Diverse persone che leggono MVC in luoghi diversi ne prendono idee diverse e le descrivono come "MVC". Se ciò non crea abbastanza confusione, si ottiene l'effetto di incomprensioni di MVC che si sviluppano attraverso un sistema di sussurri cinesi.

Tuttavia, continua fornendo una delle spiegazioni più convincenti di ciò che motiva MVC:

Il cuore di MVC è quello che chiamo presentazione separata. L'idea alla base della Presentazione separata è quella di fare una chiara divisione tra oggetti di dominio che modellano la nostra percezione del mondo reale e oggetti di presentazione che sono gli elementi della GUI che vediamo sullo schermo. Gli oggetti di dominio dovrebbero essere completamente autonomi e funzionare senza riferimento alla presentazione, inoltre dovrebbero essere in grado di supportare più presentazioni, possibilmente contemporaneamente.

Puoi leggere l'intero articolo di Fowler qui .

Penso che questo dipenda molto dal problema che stai affrontando. Vedo la separazione come segue:

Modello : come rappresentiamo i dati? Ad esempio, come posso passare dai miei oggetti a una memoria permanente come un DB -> come posso salvare il mio oggetto "Utente" nel database?

Controller : cosa sto facendo? Questa è l'azione che sta avvenendo e che cosa, a livello concettuale, deve essere eseguita. Ad esempio, quali fasi sono necessarie per fatturare un utente? NB, ciò può influire su qualsiasi quantità di oggetti, ma non è a conoscenza di come vengono mantenuti nel DB.

Visualizza : come si esegue il rendering del risultato?

Il problema che sento che stai vedendo è che molte applicazioni web sono un'interfaccia CRUD (Create-Retrieve-Update-Delete) glorificata su un DB. vale a dire che al controller viene detto di "aggiungere un utente", e quindi semplicemente dice al modello di "aggiungere un utente". Non si ottiene nulla.

Tuttavia, nei progetti in cui le azioni svolte non si applicano direttamente alle modifiche del modello, un controller rende la vita molto più semplice e il sistema più gestibile .

Non dovresti.

Vorrei riformularlo. È necessario utilizzare un'architettura che separa la logica dalle viste. Se necessario, è necessario utilizzare un'architettura che utilizza un controller (come MVC) se è richiesta una logica che non si adatta necessariamente a un modello (come, diciamo, un attraversamento di alberi che analizza blocchi di URL).

Venendo da CI e Yii, ho pensato che avere un controller dedicato fosse un'idea davvero interessante. Tuttavia, quando si sviluppano applicazioni con interfacce RESTful appropriate, la necessità di un controller di gestire la logica non specifica del modello sembra diminuire. Quindi, quando mi sono trasferito a Django e poi a Pyramid (nessuno dei quali segue completamente l'architettura MVC), ho scoperto che il controller non era in realtà un componente richiesto per le applicazioni che stavo costruendo. Si noti che entrambi i framework dispongono di funzionalità "controllerish", come URL Dispatching in Pyramid, ma è una cosa di configurazione, non una cosa di runtime (come CController in Yii).

Alla fine della giornata, ciò che è veramente importante è la separazione della vista dalla logica. Questo non solo risolve le cose in termini di implementazione, ma consente anche agli ingegneri FE / BE di lavorare in parallelo (quando lavorano in un ambiente di squadra).

(Nota a margine: non sviluppo applicazioni Web in modo professionale, quindi potrebbe esserci qualcosa che mi manca)

Sì, la terminologia su questo è un casino. È difficile parlarne perché non hai mai capito cosa significhi qualcuno con i termini.

Per quanto riguarda il motivo per cui un controller separato, il motivo potrebbe dipendere dalla versione del controller di cui stai parlando.

Potresti desiderare un controller perché quando esegui i test la vista ha un sacco di widget che non hai scritto e che probabilmente non vuoi testare. Sì, hai separato l'implementazione dall'ereditarietà, quindi puoi usare uno stub o un finto per testare altre cose, ma quando testi la tua visione concreta in sé è più difficile. Se avessi un controller che non aveva widget con lo stesso codice, potresti provarlo direttamente e forse non è necessario testare i widget tramite script.

Le altre versioni di IMHO sono più difficili da mostrare per un vantaggio concreto. Penso che sia principalmente un problema di separazione delle preoccupazioni: separa le preoccupazioni della GUI visiva pura dalla logica che si applica alla GUI ma non fa parte del modello di business (cose come, tradurre gli aggiornamenti dal modello in cui i widget dovrebbero essere visibili). Ma in pratica è probabile che le due classi siano così strettamente accoppiate (anche se comunicano attraverso le interfacce) che è difficile essere troppo sconvolti nel fonderle in una sola vista e tenere d'occhio i modi in cui la funzionalità potrebbe essere più riutilizzabile se fossero divisi.

In poche parole: separazione delle preoccupazioni. A parte tutto il discorso sul modo "corretto" di fare le cose, avere un codice più pulito, ecc. Puoi solo dire che MVC ti consente di riutilizzare più facilmente il tuo codice. Fondamentalmente programmi i tuoi modelli e i tuoi controller e puoi usarli indistintamente in un'app web, un'app desk, un servizio, ovunque senza troppi sforzi.

Bene, il motivo di base per l'utilizzo di una struttura MVC si presenta in una configurazione industriale, in cui un singolo processo di lavoro, un singolo modello è seguito per lo sviluppo di qualsiasi applicazione. Pertanto, nel caso in cui il progetto passi da un modulo di un'organizzazione a un altro, è molto più semplice fornire una migliore comprensione dello scenario di lavoro. Incorpora la chiarezza del lavoro.
Mentre tu, come individuo, avresti un approccio diverso per la tua applicazione, tu quando lavori in modo combinato con un associato, prima discuteresti e atterri su un modello comunemente concordato dai due (tu e il tuo associato). E in tal caso, separa le responsabilità assegnate a te e al tuo associato rispettivamente con un margine distintivo.

Penso che MVC sia usato solo una parola d'ordine dai teorici che sono manager. Tuttavia, detto ciò, l'attuale iterazione del web con HTML5 prevalente, design reattivo e cercando di creare una singola linea di programmazione di database che funzionerà sul web e su un iPhone si presta alle idee generali di MVC. La tecnologia Web front-end si sta letteralmente muovendo alla velocità della luce in questo momento con Jquery, nuove iterazioni del controllo CSS, mentre il lato server delle cose si sta muovendo al ritmo di una lumaca.

Alla fine, tutto sul server sarà davvero solo servizi o "applet" che invieranno i dati al front-end e, a seconda del tipo di client che possiedi, tali dati verranno consumati e visualizzati in modo diverso. In tal senso, MVC ha un senso.

A questo proposito, credo nell'attuale mondo reale, l'MVVM è davvero un "modello" migliore o qualunque cosa tu voglia chiamarlo rispetto a un controller perché un controller deve sempre tornare al modello per cambiare la vista e questo è lento . Nel modello MVVM ViewModel può fornire aggiornamenti immediati alla vista. Inoltre, il modello MVVM promuove i principi di progettazione RESTful IMHO.