Perché dovrei adottare MVC? [duplicare]

La prima cosa da considerare è il metodo di sviluppo, leggi su test driven, comportamento guidato ecc. Ciò rende molto diverso.

La seconda considerazione è la scelta del sistema di sviluppo. MVC hai iniziato con lavori per molti sistemi ma non per tutti. Ad esempio, se hai bisogno di creare una chat, esistono tecnologie molto migliori (pensa NodeJS, ecc.) Che rendono la vita più facile.

MVC in generale si adatta al lavoro CRUD e può essere esteso in molti modi, ma questo è l'approccio di base. All'interno di MVC ci sono molte altre opzioni da fare. Ad esempio: considera una pagina con molti widget. Come caricheresti ogni widget. È una chiamata separata al server, è una richiesta interna, è un record del database, ecc. Pensa prima di iniziare un progetto.

MVC: il tuo pensiero è sbagliato:

I also need to create models for each page and this is all confusing to me.

Leggi di più su MVC e su alcuni approcci di sviluppo di base. Ad esempio, la sensazione che devi fare un sacco di lavoro duplicato non è vera. In puoi darti un esempio di come abbiamo impostato rapidamente un'applicazione concettuale. Questo non funziona per tutte le applicazioni, ma per CRUD di base funziona bene.

database

Per prima cosa costruiamo le tabelle del database, quindi strutturiamo i dati in modo corretto con le relazioni richieste.

Esegui scaffold

Usiamo CakePHP ma mi aspetto che sia possibile anche con YII: impostiamo una variabile che ci fornisce un'interfaccia di base in modo che possiamo testare e inserire alcuni dati:

link

Quindi ottieni un'interfaccia completa (standard) in cui puoi lavorare. Non è personalizzabile ma dà un buon feeling con i dati del progetto.

Genera modelli, controllori, viste

Quando siamo soddisfatti, generiamo il codice per i modelli, i controller, le viste (sì: non lo scriviamo costantemente a mano).

link

Questo darà lo stesso aspetto dell'applicazione poiché lo scaffold ma ha generato tutti i file necessari.

Avvia sviluppo

Da qui in poi inizi lo sviluppo. In base ai tuoi desideri puoi iniziare con alcune implementazioni di layout, ma è anche possibile iniziare con alcune altre parti. Questo è davvero il punto in cui inizi lo sviluppo.

Attività di esempio:

• Rimuovi o aggiungi controller (i controller non sono collegati 1 su 1 ai modelli!)
• Implementa alcuni fogli di stile CSS o fogli di stile per avere la sensazione dell'applicazione
• Cuocia un plugin per strutturare il codice separatamente (elimina le parti più complesse)
• Implementa i metodi del modello per ottenere i dati corretti e chiamarli dalle viste
• Aggiungi relazioni personalizzate tra i modelli
• Implementa l'autenticazione (non iniziare con questo il più delle volte).
• ecc.

Quindi, i primi passi sono pensare alla struttura (non cercare di ottenere l'intera applicazione in una volta sola) ma solo il pezzo principale come utenti, login e attività (compiti per esempio).

Quindi rendili funzionanti e di bell'aspetto. Ristruttura il codice standard che hai ottenuto.

In generale funziona meglio avere controller, modelli, viste, ecc. separati. Hai ragione, c'è qualche duplicazione in esso, ma non è proprio una duplicazione. L'azione di visualizzazione potrebbe sembrare uguale ma non lo è. Invia altri dati, richiede un metodo di modello aggiuntivo specifico ecc.

Because so far, it takes much more time to create a small site using MVC than using my own programming schema.

Questo è il punto cruciale del tuo post e sui pattern in generale. La maggior parte delle persone là fuori ha l'impressione che ogni problema sia risolto al meglio da un modello o nel tuo caso da una disposizione di più modelli (MVC). Sfortunatamente questa non è la verità, dal momento che si possono immaginare casi dello stesso problema in un numero infinito di contesti, che si differenziano in parte pesantemente nel senso di complessità.

I modelli hanno dimostrato di risolvere problemi specifici in contesti specifici , così come hai già notato, MVC non è un modello per la creazione di piccoli siti / progetti di sviluppo, ma per ottenere una perdita di accoppiamento tra il tuo modello, vista e controllano che sono relativamente facili da scambiare. Se non pianifichi di cambiare nessuno di questi in futuro, MVC probabilmente non è la scelta migliore.

Quindi, come conclusione, vedi che applicare i pattern dipende da:

• il problema
• il contesto
• requisiti di qualità
• I vantaggi predominano gli svantaggi di esso

Nel caso di MVC hai i seguenti vantaggi:

• La vista può essere facilmente scambiata
• le stime dello sforzo per le rettifiche sono più facili, perché puoi individuare meglio l'impatto delle modifiche
• Il tuo modello può essere testato nella maggior parte dei casi indipendentemente dal controller e visualizza

e svantaggi:

Lo sforzo
• per l'implementazione aumenta
• con il modello cambia tutte le viste su di esso devono essere mantenute coerenti
• grande impegno in anticipo per impostare il framework di base (interfacce, eventi) al fine di soddisfare i requisiti specifici

Perché non userete un framework semplice come Laravel è incredibile credetemi Ed è un framework moderno e non complicato come Yii