In che modo l'utilizzo di MVC nello sviluppo Web differisce sostanzialmente dall'utilizzo originale del pattern? [chiuso]

La digitazione o il linguaggio non hanno alcun impatto, quindi ignoralo.

Il modello è lo stesso, in quanto titolare di tutti i dati trasmessi per la visualizzazione.

C'è una differenza nella Vista - dove l'originale ha costruito una GUI che era persistente, l'equivalente Web costruisce una GUI ogni volta che viene fatta una richiesta dal browser client. Tuttavia, entrambi stanno facendo lo stesso tipo di lavoro (approssimativamente) - costruendo una vista, è solo che uno è persistente e l'altro transitorio. Le operazioni su uno chiamano direttamente il controller per manipolare gli elementi, mentre l'altro ha un browser come "proxy" per questo, solo chiamando il controller quando si fa clic sui collegamenti che richiedono una vista aggiornata.

Questo suggerisce che la parte Controller è la differenza principale - mentre l'originale usato per indirizzare i messaggi ai gestori di eventi per manipolare gli elementi della GUI, la versione web è più interessata a instradare la richiesta per una vista.

Quindi direi che c'è poca differenza da un punto di vista concettuale, anche se grandi differenze nell'implementazione, ma allora si potrebbe dire questo su un sistema MVC creato usando C ++ MFC e un altro creato usando Swift e Cocoa per esempio. Immagino che potresti creare un sistema desktop MVC che ricreasse il display GUI ogni volta che veniva premuto un collegamento (e potrei dire che succede comunque, se fai clic su un pulsante che fa apparire una finestra di dialogo, crea una vista completamente nuova per te). Allo stesso modo, la persistenza dei dati è la stessa: molte GUI spesse scrivono direttamente in un database e sebbene non recuperino lo stato per ogni richiesta, l'utilizzo dello stato di sessione o meno non è esattamente un aspetto fondamentale di MVC.

L'uso originale di MVC nei framework desktop GUI è fondamentalmente diverso dai framework MVC lato server come RoR o ASP.Net MVC. L'architettura MVC web è ispirata dal MVC originale (da cui il nome) ma non è lo stesso schema, dal momento che la richiesta-risposta o il web è fondamentalmente diverso da un'interfaccia grafica desktop interattiva. Se provi a pensarlo come lo stesso schema ti confonderai (come dice chiaramente il ragazzo che stai citando), quindi è meglio pensarlo come due modelli diversi per architetture diverse che condividono lo stesso nome.

Ok, morderò, ma un piccolo disclaimer: Non ho alcuna fonte di supporto (almeno a cui posso collegarmi, potrebbero essere là fuori) e questo è scritto esclusivamente dal mio comprensione / interpretazione delle intenzioni originali di MVC che potrebbero non essere corrette.

Originariamente MVC aveva senso perché i motori GUI gestiti da eventi gestiti pesantemente (come un gestore di finestre o un DOM) non esistevano. Hai avuto un modello, una vista (monitor) e un controller (tastiera). Ora, ogni volta che qualcosa è stato attivato sul dispositivo di input (tastiera) è necessario modificare il modello e successivamente aggiornare la visualizzazione. Questo era il solito paradigma dell'interfaccia utente in quel momento - poi sono arrivati i gestori di finestre.

I gestori di finestre hanno sottratto il dispositivo di input, legando insieme la vista e il controller. Non hai più ricevuto una "tastiera y è stata premuta" -event, ma piuttosto una "casella di testo1 aveva una y applicata" -event, o nel caso di un mouse non era più "mouse cliccato al punto (400, 500)" , ma "il mouse ha fatto clic sopra il pulsante 1". L'interfaccia utente era ora interattiva , e sono sicuro che la maggior parte dei gestori di finestre utilizzano puro MVC sotto il cofano e mantiene un modello di dove sullo schermo button1 è e quale elemento ha il focus ecc. Ecc.

Avanti veloce; le persone continuavano a usare la parola "MVC" nella programmazione interattiva della GUI, ma in un certo senso perse il suo significato. Ricordo quando ero uno studente e imparammo a conoscere MVC, e provai in qualche modo ad adattarlo allo java swing. Non ho mai capito completamente perché dovevamo farlo, dato che non aveva assolutamente senso ... Qual era l'input adesso? Perché dovrei separare l'aspetto dei pulsanti dalle opzioni di input quando entrambi erano già uniti per me nella classe jButton? Questo è dove penso che un sacco di confusione provenga da ...

Ora, un altro piccolo e popolare modo di programmare un'interfaccia utente sta sfruttando l'HTTP e il world wide web. MVC lato server è rinato con una tonnellata di framework che si aprono abbracciando il pattern nella sua intenzione originale. Qualcosa accade come input (una richiesta HTTP) che altera il modello e infine aggiorna la vista (facendo una risposta di alcuni html).

Tutto bene. Abbiamo interfacce grafiche interattive con gestori di finestre (come WPF, JavaFX, Qt, ecc.) E abbiamo GUI non interattive (come HTTP o MMI incorporati).

Quindi quali di questi sono MVC lato client sul Web? Direi che somigliano più alle GUI interattive che a quelle non interattive. Hai un DOM che gestisce sia l'aspetto che i comportamenti e hai una vista / controller strettamente legata (almeno secondo la definizione originale di MVC). Secondo me questo porta alla stessa conclusione che per la programmazione desktop; MVC originale non si adatta e qualcosa come MVP (che molte "implementazioni MVC" assomigliano molto a) o MVVM ha più senso.

Quindi, torna alle tue domande originali:

In other words, does the fact that we're ususing

JavaScript, a loosely typed and very different language from the ones used when the MVC pattern was designed

and use the DOM + CSS, a predefined simplified method of rendering content, whereas before web development, applications used their own rendering engines or rendering libraries to display content, perhaps making the MVC pattern more necessary

change the way we should define and use the MVC pattern in a web development environment? Are there any fundamental differences in the original usage of MVC in a non web environment and using MVC in web development?

IMHO, sì. Esistono differenze fondamentali nell'utilizzo originale di MVC in un ambiente non Web e utilizzo di MVC nello sviluppo web e probabilmente dovremmo cambiare il modo in cui lo definiamo, ma a questo punto penso sia troppo tardi. Lascia che il buzzer continui a dire MVC, mentre il resto di noi si riferisce a "Original MVC" o "Buzzword MVC":)