MVC è solo il SEO della programmazione PHP?

8

Ci sono circa un miliardo di "framework PHP". E la maggior parte di loro si fatturano come seguendo il pattern MVC. Benché sia possibile superare lo stile di codifica di osCommerce (logica di elaborazione strongmente mescolata con SQL e HTML), esistono sicuramente approcci più semplici e facili da seguire per ottenere un progetto di applicazione gestibile.

Il concetto MVC originale era mirato alle applicazioni GUI. E per Gtk / Python sembra fattibile seguirlo di conseguenza. Ma le web app PHP non funzionano su live Views (elementi della GUI) e su un persistente runtime del controller. Certamente è un termine improprio se descrive solo il codice utilizzato + il raggruppamento di directory o la denominazione della classe.

"MVC" sembra essere usato come buzzword per i framework PHP. E in effetti ho visto uno o due framework PHP maturi che lo ammettono, ma ridefinendo comunque la frase per corrispondere a interna.
Quindi è generalmente olio di serpente? Perché non viene utilizzata una terminologia migliore e un concetto più ragionevole per propagare PHP mantenibile?

Alcuni ragionamenti elaborativi

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

Modelli : in teoria, i modelli dovrebbero essere grossi e contenere la logica aziendale e i controller dovrebbero essere thin handler (input e gt; output). In realtà i framework PHP sostengono i modelli shallow . CI e Symfony per esempio equivalgono a Model == ORM. Anche l'input HTTP viene gestito dal controller, non viene considerato come modello.

Visualizzazioni : soluzioni alternative con AJAX scontate, non possono esserci visualizzazioni su pagine web. I framework PHP continuano a pompare pagine. L'interfaccia segue ancora in modo efficace il modello HTTP ordinario, non c'è alcun vantaggio rispetto alle applicazioni non MVC. (E, infine, nessuno dei framework PHP diffusi è in realtà in grado di generare viste GUI anziché HTML. Ho visto una libreria PHP che può gestire Gtk / Console / Web, ma i framework no.)

Controller : non sono sicuro. Probabilmente non è necessario che i controller siano long-running e persistentemente attivi nel modello MVC. Nel contesto del framework PHP, sono tuttavia principalmente gestori di richieste. Non è davvero qualcosa di cui discutere, ma sembra solo un po 'buzzword.

Ci sarebbero dei migliori descrittori? Ho visto acronimi come PMVC o HMVC lanciati in giro. Anche se le descrizioni diventano più ambigue, forse queste descrivono gli attuali framework web meno hokey?

    
posta mario 11.09.2010 - 09:00
fonte

4 risposte

12

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

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

Il Controller e Model è dove le cose differiscono, come hai spiegato tu. In PHP il modello tende ad 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, se possibile solo una volta per pagina.

Quindi il nome "Model-View-Controller" è perfettamente logico, anche se un'implementazione diversa nelle app GUI e nelle app Web.

    
risposta data 22.09.2010 - 14:41
fonte
3

Poiché non sono a conoscenza dei framework PHP, questo è visto da una visualizzazione del linguaggio di basso livello.

Modelli:

in theory, Models should be fat and contain business logic

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 potresti anche inviare lo stesso modello o un modello parziale in formato JSON al client.

Non direi logica aziendale, è più simile alla logica dei dati (convalida, interazione con il database, importazione / esportazione, ...).

and controllers should be thin handlers (input->output)

Le tue classi di controller interagiscono con le classi del modello, sono davvero sottili.

In base all'output, fai qualcosa con i Modelli ... e restituisci una ModelView al client ...

In reality the PHP frameworks advocate shallow Models. CI and Symfony for example equate Model == ORM. Even HTTP input is handled by the controller, isn't treated as model.

Non sono a conoscenza di quei framework PHP ...

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

Questo è esattamente ciò che accade in ASP.NET MVC 2 e non c'è niente di sbagliato in esso,
Non so come sarebbe successo con PHP, ma immagino che sarebbe strettamente correlato.

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

Visualizzazioni:

workarounds with AJAX discounted, there can't be Views on web pages. PHP frameworks still pump out pages.

Non vedo perché non potrebbe, 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 a conoscenza di quei framework PHP, ma in ASP.NET MVC 2 funziona in questo modo.

The interface still effectively follows the ordinary HTTP model, there's no advantage over non-MVC applications. (And lastly, none of the widespread php frameworks can factually output to GUI Views instead of HTML. I've seen a PHP library that can operate Gtk/Console/Web, but the frameworks don't.)

L'unico vantaggio che si ottiene (e che è lo stesso con le normali applicazioni) è la separazione in Model (Data) + View (GUI) + Controller (Logic). In modo simile, non vedrai un framework C ++ che possa essere effettivamente pubblicato in HTML o JSON invece che in viste GUI.

Controller:

I'm unsure. Controllers probably don't need to be long-running and persistently active in the MVC model. In PHP framework context, they're however mostly request handlers. Not really something to get argumentative about, but it just feels slightly buzzwordish.

MVC è un'architettura / pattern software, in cui viene eseguito il controller e per quanto tempo non è necessario.

    
risposta data 12.09.2010 - 14:19
fonte
1

But PHP web apps don't operate on live Views (GUI elements) and a persistent Controller runtime.

No, certo che sì!

Pensa alle applicazioni AJAX, quindi la vista chiede qualcosa al controller e ottiene una vista parziale indietro,
questa vista o i dati vengono quindi inseriti in qualche punto della pagina e quindi aggiornati dal vivo.

Anche il controller è persistente perché puoi usare i cookie / sessioni.

"MVC" seems to be used like a buzzword for PHP frameworks.

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

is MVC just the SEO of php programming?

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

    
risposta data 11.09.2010 - 11:19
fonte
-1

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

    
risposta data 11.09.2010 - 12:59
fonte

Leggi altre domande sui tag