Quali sono le carenze di MVC? [chiuso]

Devi sempre ricordare che MVC è un pattern relativo all'interfaccia utente. Se stai costruendo un'applicazione complessa dovresti prendere tutto, che non è correlato all'interfaccia utente, dalle triplette MVC a qualsiasi altra classe, sottosistema o livello.

È stato il mio più grande errore. Ho passato molto tempo a capire questa semplice regola:

• Non diffondere un pattern MVC nell'intera applicazione,
• Limita solo le cose relative all'interfaccia utente.

Controlla sempre se il codice che scrivi è logicamente nella posizione corretta, il che significa che si inserisce logicamente nell'area di responsabilità della classe in cui lo hai inserito. In caso contrario, sposta il codice non appena lo capisci.

Tutti i pattern che chiami alternative MVC (ad esempio Model-View-Presenter, Model-View-ViewModel) sono solo un modo per implementare il concetto MVC generale.

Secondo me ci sono due tipi di MVC: puro e impuro (per la mancanza di una parola migliore:)

Pure MVC è ciò che è stato introdotto nelle chiacchiere:

Questoeraintesoperapplicazionidipersonalcomputing/desktop.Comepuoivedere,ilmodelloinformaleopinionidieventualiaggiornamenti/modificheapportateadesso.Noncosìcon(impuro)MVC.

L'altroMVC(impuro)propagandatoperleapplicazioniWebèpiùunPAC( Presentation-astrstraction-control ) schema invece del classico MVC sopra. Questo è più di organizzazione del codice e separazione delle preoccupazioni:

• Modello : astrazione per i dati memorizzati
• Controllo : di solito ciò che è noto come livello della business logic e parte dell'applicazione responsabile del routing delle richieste HTTP alla logica di business corrispondente (ovvero controller)
• Visualizza : per lo più visualizza modelli che formattano i dati dal modello e li restituiscono al client. Il modello non invia MAI aggiornamenti alla vista, né la vista 'iscrive' per gli aggiornamenti da un modello. Sarebbe un incubo accoppiato. Quindi è più simile al PAC che al vero MVC.

Ora, ecco come viene solitamente strutturata un'applicazione web:

1. Front-end : MVC sul client che utilizza framework come Backbone.js ecc., Questo è il modulo MVC "true" in sostanza.
2. Back-end : di nuovo, hai MVC / PAC (impuro) per l'organizzazione del codice e la separazione delle preoccupazioni
3. App web globale (per l'applicazione Web nel suo complesso): se disponi di un backend RESTful che restituisce solo dati JSON, l'intero backend può essere percepito come un modello per applicazione client front-end in cui la vista e il controller risiedono in sostanza.

Quindi quali sono alcuni svantaggi di MVC ? Bene, il modello ha superato la prova del tempo quindi non ci sono molti che contano molto più che essere un po '"complicato". Vedete, l'MVC è un modello composto - implementa il modello di strategia / osservatore e tutti sono ben disposti per formare uno schema di alto livello.

Dovresti usarlo ovunque? Forse no. Applicazioni web estremamente complesse possono essere suddivise in più livelli! Potrebbe non essere in grado di farla franca solo con i livelli View / Business Logic / Data. L'infrastruttura / organizzazione globale può ancora essere MVC-ish, ma solo a livello macroscopico.

Ecco un esempio in cui solo MVC di per sé può essere una cattiva scelta : provare a progettare un sistema di controllo del traffico aereo o un'applicazione di elaborazione di prestiti / mutui per una grande banca - solo MVC di per sé sarebbe una cattiva scelta . Avrai inevitabilmente bus di evento / code di messaggi con un'architettura a più livelli con MVC all'interno di singoli livelli e possibilmente un progetto MVC / PAC generale per mantenere la base di codice meglio organizzata.

L'errore che molte persone fanno con i modelli di design è vederlo funzionare magnificamente in un unico posto e quindi provare ad applicarlo ovunque.

Se hai lavorato in un posto per un po ', puoi quasi datare un pezzo di codice vedendo quali tecnologie / modelli / pratiche di progettazione erano in voga al momento, ad es. singleton / dipendenza da iniezione / TDD ecc ecc.

Per quanto riguarda dove non usarlo. Bene, ovunque non si applichi un elemento della tripletta MVC. Le applicazioni della console potrebbero non implementare affatto un'interfaccia. I programmi di utilità potrebbero non avere un modello. E probabilmente, se non hai né un modello né una vista, non hai bisogno di un controller.

Il problema si presenta raramente con il concetto, più con l'implementazione. Non importa quanto sia buono il paradigma, prenditi il tempo per vedere se è adatto al problema in questione.

MVC, come ogni paradigma non integrato nella tua piattaforma di sviluppo, è una maggiore complessità. Lo svantaggio è che potresti finire per separare classi che non dovrebbero essere separate, e diminuire la chiarezza di quanto siano strettamente legate. (Oppure, per progetti banali, persino offuscando il tuo codice.)

L'alternativa al primo problema è quella di separare tale codice in sottoprogetti indipendenti; l'alternativa per il secondo è il codice non separato, sia nella classe che nel modello di file.

La mia comprensione dell'applicazione di MVC / MV * sta seguendo il principio di Separation of Concerns (SoC) - separando programmi / codici in sezioni / pezzi distinti in modo che ogni sezione possa affrontare un problema separato (Rif: link )

ci sono molti vantaggi quando si separano i dubbi: uno non influirà su un altro e gli sviluppatori potrebbero lavorare su un'unità senza influenzare il resto, ecc. & etc ... MVC non è l'unico modello che segue SoC, in pratica, lo stesso OOP è un grande concetto per rompere le cose in unità.

MVC / MV * sono molto utili quando si gestisce lo sviluppo correlato all'interfaccia utente, mentre al di sotto ci potrebbero essere più schemi - fabbrica, singleton, facciata e così via. La maggior parte dei grandi progetti consiste di più livelli che gestiscono aspetti diversi, ma l'interfaccia utente potrebbe non essere un must per alcuni casi. Potresti vedere molto MVC, perché molti progetti hanno elementi dell'interfaccia utente.

Quindi, mentre parli degli svantaggi di MVC, dipende davvero dai progetti che stai facendo - ha un'interfaccia utente? richiede grande scalabilità / estensibilità? ha molte interazioni tra l'interfaccia utente e il sistema dietro? ad esempio, una semplice pagina Web di informazioni non richiede affatto MVC, a meno che non si preveda di estenderla a una grande pagina interattiva in futuro.

Quindi per valutare MVC (o più generale - un modello di progettazione), dargli un contesto e pensare a complessità, scalabilità, testabilità, manutenzione, vincoli temporali, ecc. & ecc.