MVC è solo il SEO della programmazione PHP?

Ci sono circa un milione di "framework PHP". E la maggior parte di loro si considera come seguendo il modello MVC. Sebbene sia gradito superare lo stile di codifica osCommerce (logica di elaborazione fortemente mescolata a SQL e HTML), esistono sicuramente approcci più semplici e facili da seguire per ottenere un design di applicazione sostenibile.

Il concetto originale MVC era mirato alle applicazioni GUI. E per Gtk / Python sembra possibile seguirlo di conseguenza. Ma le app Web PHP non funzionano su viste live (elementi della GUI) e un runtime del controller persistente. È certamente un termine improprio se descrive solo il codice usato + il raggruppamento di directory o la denominazione delle classi.

"MVC" sembra essere usato come una parola d'ordine per i framework PHP. E in realtà ho visto uno o due framework PHP maturi ammetterlo, ma ridefinendo comunque la frase in modo che corrisponda a quella interna.
Quindi è generalmente olio di serpente? Perché non viene utilizzata una terminologia migliore e viene propagato un concetto più sensato di PHP gestibile?

Alcuni ragionamenti elaborativi

Perché sospetto che le implementazioni di PHP non seguano il modello MVC reale:

Modelli : in teoria, i modelli dovrebbero essere grassi e contenere la logica aziendale, ei controller dovrebbero essere gestori sottili (input-> output). In realtà i framework PHP sostengono i modelli superficiali . CI e Symfony, ad esempio, equivalgono a Model == ORM. Anche l'input HTTP è gestito dal controller, non è trattato come modello.

Viste : soluzioni alternative con AJAX scontato, non ci possono essere viste sulle pagine web. I framework PHP continuano a pompare pagine. L'interfaccia segue ancora efficacemente il normale modello HTTP, non c'è alcun vantaggio rispetto alle applicazioni non MVC. (E, infine, nessuno dei framework php diffusi può effettivamente produrre output in GUI Views anziché HTML. Ho visto una libreria PHP che può operare Gtk / Console / Web, ma i framework no.)

Controller : non sono sicuro. Probabilmente i controller non devono essere di lunga durata e permanentemente attivi nel modello MVC. Nel contesto del framework PHP, sono comunque principalmente gestori di richieste. Non è proprio qualcosa di cui discutere, ma sembra un po 'frizzante.

Ci sarebbero descrittori migliori? Ho visto acronimi come PMVC o HMVC lanciati in giro. Sebbene le descrizioni diventino più ambigue lì, forse potrebbero descrivere gli attuali framework web meno hokey?

Penso che tu lo stia guardando in modo completamente sbagliato. Un'app GUI e una pagina Web sono mondi a parte quindi la stessa identica definizione di MVC non funzionerà mai per entrambi. MVC è più sull'ideale: separare alcune parti dell'app come display e logica.

In PHP (o nel web in generale), una vista è la stessa pagina web: l'output HTML. Non è "live" secondo la tua definizione, ma fai semplicemente clic sui link per tornare al controller (ovvero un'altra richiesta di pagina).

Il controller e il modello è dove le cose differiscono, come hai spiegato. In PHP il modello tende a essere il livello dati, interagendo con il database e così via. Ma sta ancora modellando la situazione e il controller controlla ancora il flusso dell'applicazione, anche se solo una volta per caricamento della pagina.

Quindi il nome "Model-View-Controller" è perfettamente logico, sebbene un'implementazione diversa nelle app GUI rispetto alle app Web.

Dato che non sono a conoscenza dei framework PHP, questo è visto da una visione linguistica di basso livello.

Modelli:

in teoria, i modelli dovrebbero essere grassi e contenere la logica aziendale

Questo è completamente da fare, non vedo cosa PHP abbia a che fare con questo ...

I modelli sono classi di dati in PHP che potrebbero probabilmente comunicare con il database,
quindi è possibile inviare al client lo stesso modello o un modello parziale in formato JSON.

Non direi business logic, è più simile alla logica dei dati (validazione, interazione con il database, import / export, ...).

e i controller dovrebbero essere gestori thin (input-> output)

Le tue classi Controller interagiscono con le classi Model, sono davvero sottili.

In base all'output, esegui alcune operazioni con i modelli ... E restituisci un ModelView al client ...

In realtà i framework PHP sostengono i modelli superficiali. CI e Symfony, ad esempio, equivalgono a Model == ORM. Anche l'input HTTP è gestito dal controller, non è trattato come modello.

Non sono davvero a conoscenza di quei framework PHP ...

Ma l'input HTTP deve essere gestito prima che raggiunga il controller,
puoi facilmente creare una classe che trasforma i dati GET e POST in routing e parametri corretti.

Questo è esattamente ciò che accade in ASP.NET MVC 2 e non c'è nulla di sbagliato in questo,
non so come ciò accadrà con PHP ma immagino che sarebbe strettamente correlato.

Potresti anche facilmente trasformare i dati GET e POST in un modello, il modello potrebbe contenere la logica del costruttore per questo. Oppure alcune classi separate potrebbero essere aggiunte a tale scopo.

Visualizzazioni:

soluzioni alternative con AJAX scontato, non è possibile visualizzare viste sulle pagine Web. I framework PHP continuano a pompare pagine.

Non vedo perché non sia possibile, l'unica differenza è il protocollo e PHP può restituire JSON, ecc ...

Una pagina è la tua vista e può richiedere e aggiornare tramite AJAX + JSON.
Ancora una volta, non sono davvero a conoscenza di quei framework PHP ma in ASP.NET MVC 2 funziona in questo modo.

L'interfaccia segue ancora efficacemente il normale modello HTTP, non c'è alcun vantaggio rispetto alle applicazioni non MVC. (E infine, nessuno dei framework php diffusi può effettivamente produrre output in GUI Views anziché HTML. Ho visto una libreria PHP che può operare Gtk / Console / Web, ma i framework no.)

L'unico vantaggio che ottieni (e questo è lo stesso con le normali applicazioni) è la separazione in Model (Data) + View (GUI) + Controller (Logic). Allo stesso modo, non vedrai un framework C ++ che può effettivamente essere generato in HTML o JSON invece che nelle viste GUI.

controller:

Non sono sicuro Probabilmente i controller non devono essere di lunga durata e permanentemente attivi nel modello MVC. Nel contesto del framework PHP, sono comunque principalmente gestori di richieste. Non è proprio qualcosa su cui discutere, ma sembra un po 'frizzante.

MVC è un'architettura / modello software, in cui il controller funziona e per quanto tempo non si raduna.

Ma le app Web PHP non funzionano su viste live (elementi della GUI) e un runtime del controller persistente.

No, lo fanno sicuramente!

Pensa alle applicazioni AJAX, quindi la vista chiede qualcosa al controller e ottiene una vista parziale,
questa vista o i dati vengono quindi inseriti da qualche parte nella pagina e quindi aggiornati in tempo reale.

Il controller è persistente anche perché è possibile utilizzare cookie / sessioni.

"MVC" sembra essere usato come una parola d'ordine per i framework PHP.

MVC è un'architettura software, alcuni framework potrebbero usarlo come un buzz, ma altri lo fanno correttamente ...
Vedi un elenco di alcuni framework su Wikipedia .

MVC è solo il SEO della programmazione php?

MVC e SEO sono due cose a parte, ma sì ... MVC sta diventando sempre più popolare.

Secondo me l'uso di MVC in php porta i programmatori sul web. È più facile passare, ad esempio, da Java a PHP quando sai come lavorare con MVC.