Perché dovrei usare un pattern MVC?

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

I don't find it terribly useful to think of MVC as a pattern because it contains quite a few different ideas. Different people reading about MVC in different places take different ideas from it and describe these as 'MVC'. If this doesn't cause enough confusion you then get the effect of misunderstandings of MVC that develop through a system of Chinese whispers.

Tuttavia, continua a dare una delle spiegazioni più convincenti su ciò che motiva MVC:

At the heart of MVC is what I call Separated Presentation. The idea behind Separated Presentation is to make a clear division between domain objects that model our perception of the real world, and presentation objects that are the GUI elements we see on the screen. Domain objects should be completely self contained and work without reference to the presentation, they should also be able to support multiple presentations, possibly simultaneously.

Puoi leggere l'intero articolo di Fowler qui .

Ritengo che ciò dipenda molto dal problema che stai affrontando. Vedo la separazione come segue:

Modello - come rappresentiamo i dati? Ad esempio, come passare dai miei oggetti a una memoria persistente 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 devo passare per fatturare un utente? N.B. questo può influenzare qualsiasi quantità di oggetti, ma non sa nulla su come sono persistenti nel DB.

Visualizza - come faccio a visualizzare il risultato?

Il problema che vedo è che molte applicazioni Web sono un'interfaccia CRUD (Create-Retrieve-Update-Delete) glorificata a un DB. Ad esempio, al controllore viene detto di 'aggiungere un utente', e poi dice semplicemente al modello di 'aggiungere un utente'. Nulla è guadagnato.

Tuttavia, nei progetti in cui le azioni eseguite non si applicano direttamente ai cambiamenti nel modello, un controllore rende la vita molto più facile e il sistema più gestibile.

Non dovresti.

Fammi riformulare. Dovresti usare un'architettura che separa la logica dalle tue viste. Se necessario, dovresti utilizzare un'architettura che utilizza un controller (ad esempio MVC) se è necessaria una logica che non rientri necessariamente in un modello (ad esempio, un attraversamento di alberi che analizza i blocchi di URL).

Venendo da CI e Yii, pensavo che avere un controller dedicato fosse un'idea davvero interessante. Tuttavia, quando si sviluppano applicazioni con interfacce RESTful appropriate, la necessità di un controller per gestire la logica non specifica del modello sembra diminuire. Quindi, spostandomi su Django e poi su Pyramid (nessuno dei due segue completamente l'architettura MVC), ho scoperto che il controller non era in realtà un componente necessario per le applicazioni che stavo costruendo. Nota che entrambi i framework hanno caratteristiche "controller'ish", come l'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. Ciò non solo risolve le cose in termini di implementazione, ma consente anche agli ingegneri FE / BE di lavorare in parallelo (quando si lavora in un ambiente di squadra).

(Nota a margine: non sviluppo applicazioni web professionalmente, quindi potrebbe esserci qualcosa che mi manca)

Sì, la terminologia su questo è un casino. È difficile parlarne perché non si è mai del tutto che cosa significhi per i termini.

Per quanto riguarda il motivo per cui un controller separato, la ragione potrebbe dipendere dalla versione del controller di cui si parla.

Potresti volere un controller perché quando esegui dei test, la vista ha una serie di widget che non hai scritto e probabilmente non vuoi testare. Sì, hai separato l'implementazione dall'eredità, quindi puoi usare uno stub o un mock per testare altre cose, ma quando provi la tua vista concreta è più difficile. Se avessi un controller che non ha alcun widget che esegue lo stesso codice, puoi testarlo direttamente e forse non è necessario testare i widget tramite script.

Le altre versioni IMHO sono più difficili da mostrare un vantaggio concreto per. Penso che sia principalmente un problema di separazione delle preoccupazioni - separare i problemi puramente visivi della GUI 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 interfacce) che è difficile essere troppo sconvolti per fonderle in una sola visione, e basta tenere d'occhio i modi in cui la funzionalità potrebbe essere più riutilizzabile se fossero divisi.

In poche parole: separazione delle preoccupazioni. A parte tutti i discorsi sul modo "corretto" di fare le cose, avere un codice più pulito, ecc. Puoi semplicemente dire che MVC ti permette di riutilizzare più facilmente il tuo codice. Basicamente, programmi i tuoi modelli e i tuoi controller e puoi usarli indistintamente in un'app Web, in un'app per desktop, in un servizio, ovunque senza molto sforzo.

Bene, il motivo fondamentale per l'utilizzo di una struttura MVC si presenta in una configurazione di settore, in cui un singolo processo di lavoro viene seguito da un singolo modello per lo sviluppo di qualsiasi applicazione. Quindi, nel caso, se il progetto passa da un modulo di un'organizzazione a un altro, è molto più facile 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, quando lavori in modo combinato con un socio, prima discuteresti e atterri su un modello concordato dai due (tu e il tuo socio). In tal caso, separa le responsabilità assegnate rispettivamente a te e al tuo associato con un margine distintivo.

Penso che MVC sia usato solo come parola d'ordine dai teorici che sono manager. Tuttavia, detto questo, l'attuale iterazione del web con HTML5 prevalente, reattivo design 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 di front-end web si sta letteralmente muovendo alla velocità della luce proprio ora con Jquery, nuove iterazioni del controllo CSS, mentre il lato server delle cose si muove al ritmo di una lumaca.

Alla fine, tutto sul server sarà in realtà solo servizi o "applet" che pompano i dati sul front-end e, a seconda del tipo di client che hai, quei dati saranno consumati e visualizzati in modo diverso. In questo senso, MVC ha senso.

A questo proposito, credo nel mondo reale attuale, MVVM è davvero un "pattern" migliore o come lo si voglia chiamare rispetto a un controller perché un controller deve sempre tornare al modello per cambiare la visualizzazione e questo è lento. Nel modello MVVM, ViewModel può fornire aggiornamenti immediati alla vista. Inoltre, il modello MVVM promuove i principi di progettazione RESTful IMHO.