MVC è ora l'unico modo per scrivere PHP?

No.

Quale schema usi sempre dipende dal compito che il tuo programma / script deve eseguire. Proprio ieri ho dovuto risolvere questo:

• mostra il mtime di due file
• mostra il numero di file temporanei in una cartella
• consentire l'eliminazione di tutti i file temporanei con un clic
• interfaccia web

So che si potrebbe sostenere che una soluzione MVC riutilizzabile sarebbe più pulita, ma ho scelto un codice sequenziale di 20 righe. Perché? È veloce. È piccolo. E ogni minuto che passo su questo è un minuto che non posso usare sul mio progetto principale.

(lascia che l'odio abbia inizio!)

La cosa a cui pensare non è se l'utilizzo di un framework MVC è giustificato, è maintainability . Certo, potrebbe essere piccolo ora, ma sarà sempre?

Bene ci sono molti altri approcci.

MVC è popolare perché si adatta alla maggior parte delle situazioni (o meglio può essere usato nella maggior parte delle situazioni) e si è affermato come standard de facto.

Ciò che si può dire è che ogni schema di programmazione / design - o più specifico architettonico - dipende da alcune classificazioni.

Questi sono spesso (ovviamente possono essere ulteriormente divisi):

• Interfaccia utente (immagini graziose, moduli ecc.)

• Applicazione (la logica dell'applicazione e le cose che devono essere protette dal client - molte parti spesso possono essere fatte nell'interfaccia utente, ad esempio javascript)

• Database - auto esplicativo

• Infrastruttura (cose di base come hard disk, sistemi server, rete, ecc.)

Ovviamente c'è sempre un approccio procedurale semplice e ingenuo, ma anche molti altri pattern che possono collegare e strutturare l'accesso e il controllo a questi livelli di base.

Mvc è uno di questi. Ma ecco alcuni esempi di altri:

link

link

link

E qui molto di più:

link

MVC è in genere il modo più naturale per separare le preoccupazioni nelle applicazioni web di medie e grandi dimensioni. Nessuno dice che devi farlo in quel modo. Se il tuo dominio suggerisce un altro modo per separare l'applicazione in parti gestibili, allora dovresti farlo in quel modo. Le probabilità sono alte anche se stabilisci una variazione del pattern MVC se separi correttamente la logica dell'applicazione.

Tutto dipende dal compito a portata di mano. Non ci sono eccezioni per questa proposizione per qualsiasi argomento. Che si tratti di MVC, Web Design, programmazione API o anche cucina. Questa è logica.

Per quanto riguarda la programmazione, per una particolare attività MVC potrebbe essere eccessivo o inadeguato. Uno script di 100 righe potrebbe essere più veloce o più gestibile. Dipende totalmente dal compito. Non è necessario caricare un'app MVC ottimamente strutturata e basata su modelli per un'API che riceverà solo una parte di dati da una tabella DB e la servirà per una particolare richiesta.

MVC è migliore nei casi in cui è possibile riutilizzare il codice o, in futuro, è necessario espanderlo o mantenerlo per qualsiasi motivo specifico.

E una nota in merito a sequenziale vs oop: tutto avviene in sequenza in un programma. Non ci possono essere due stati della stessa variabile nelle stesse condizioni. Un oggetto carrello acquisti non può avere due valori per lo stesso cliente con gli stessi prodotti con le stesse opzioni con le stesse posizioni di spedizione e dettagli fiscali. Oppure, non è possibile creare un oggetto carrello della spesa e scrivere i prodotti in esso prima che il cliente aggiunga effettivamente i prodotti al carrello. Sarebbe surreale. Qualcosa che richiede che si verifichino condizioni particolari non può accadere senza quelle particolari condizioni soddisfatte, nella programmazione. (E no - l'inizializzazione di una potenziale classe di oggetti predittivi per un potenziale oggetto dati non è rilevante).

Quindi, quindi, pensa in modo pratico: fai ciò che è in gioco e quali sono i suoi potenziali requisiti a breve, medio e lungo termine.