Quali sono gli svantaggi di MVC? [chiuso]

Uso MVC / MV * da quando ho iniziato a organizzare il mio codice anni fa. Lo uso da così tanto tempo che non riesco nemmeno a pensare a nessun altro modo di strutturare il mio codice e ogni lavoro che ho avuto dopo essere stato uno stagista era basato su MVC.

La mia domanda è: quali sono gli svantaggi di MVC? In quali casi MVC sarebbe una cattiva scelta per un progetto e quale sarebbe la (più) scelta corretta? Quando cerco alternative MVC, quasi tutti i risultati sono solo diversi tipi di MVC.

Per restringere l'ambito in modo che non si chiuda, diciamo per le applicazioni web. Lavoro sul back-end e sul front-end per diversi progetti, quindi non posso dire solo front-end o back-end.

Dovresti sempre ricordare - MVC è un modello relativo all'interfaccia utente. Se stai costruendo un'applicazione complessa, dovresti prendere tutto, che non è correlato all'interfaccia utente, dalle terzine MVC ad altre classi, sottosistemi o livelli.

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

• Non diffondere un modello MVC nell'intera applicazione,
• Limitalo solo alle cose relative all'interfaccia utente.

Controlla sempre se il codice che scrivi è logicamente nella posizione corretta, nel senso che si adatta logicamente alla sua area di responsabilità della classe in cui lo inserisci. In caso contrario, sposta il codice non appena lo capisci.

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

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

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

Questo era destinato alle applicazioni di personal computer / desktop. Come puoi vedere, il modello informa le visualizzazioni di eventuali aggiornamenti / modifiche apportate ad esso. Non così con (impuro) MVC.

L'altro (impuro) MVC che viene propagandato per le applicazioni Web è più un modello PAC ( Presentazione-astrazione-controllo ) invece del classico MVC sopra. Questo è più di organizzazione del codice e separazione delle preoccupazioni:

• Modello : astrazione per dati memorizzati
• Controllo : in genere ciò che è noto come livello di logica aziendale, nonché parte dell'applicazione responsabile dell'instradamento delle richieste HTTP alla corrispondente logica di business (aka controller)
• Visualizza : visualizza principalmente modelli che formattano i dati dal modello e li restituiscono al client. Il modello non invia MAI aggiornamenti alla vista, né la vista "sottoscrive" per gli aggiornamenti da un modello. Sarebbe un incubo di accoppiamento. Quindi è più simile al PAC che al vero MVC.

Ora, ecco come è strutturata un'applicazione Web:

1. Front-end : MVC sul client che utilizza framework come Backbone.js ecc., Questa è la forma "vera" MVC in sostanza.
2. Back-end : Ancora una volta, hai MVC / PAC (impuro) per l'organizzazione del codice e la separazione delle preoccupazioni
3. App Web globale (per l'intera applicazione Web): se si dispone di un back-end RESTful che restituisce solo dati JSON, l'intero back-end può essere percepito come un modello per l'applicazione client front-end in cui View e Controller risiedono in sostanza.

Quindi quali sono alcuni svantaggi di MVC ? Bene, il modello ha resistito alla prova del tempo, quindi non ce ne sono molti che contano molto meno che essere un po '"complicato". Vedete, l'MVC è un modello composto: implementa il modello strategia / osservatore e tutti sono ben organizzati per formare un modello di alto livello.

Dovresti usarlo ovunque? Forse no. Le applicazioni Web estremamente complesse potrebbero essere suddivise in più livelli! Potresti non essere in grado di cavartela solo con i livelli Visualizza / Logica aziendale / Dati. La struttura / organizzazione generale può essere ancora MVC-ish, ma solo a livello macroscopico.

Ecco un esempio in cui solo MVC da solo potrebbe essere una cattiva scelta: prova a progettare un sistema di controllo del traffico aereo o un'applicazione di elaborazione di prestiti / mutui per una grande banca - solo MVC da solo sarebbe una cattiva scelta. Inevitabilmente avrai bus degli eventi / code di messaggi insieme a un'architettura a più livelli con MVC all'interno di singoli livelli e possibilmente un design MVC / PAC globale per mantenere meglio organizzata la base di codice.

L'errore che molte persone commettono con i modelli di design è vedere che funziona magnificamente in un 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 di progettazione / pratiche erano in voga al momento, ad esempio singoli / iniezione di dipendenza / 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 è 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 qualsiasi paradigma non integrato nella tua piattaforma di sviluppo, è una maggiore complessità. L'inconveniente è che potresti finire in classi separate che non dovrebbero essere separate, e diminuendo la chiarezza di quanto siano strettamente legate. (O, per progetti banali, anche offuscare 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) - che separa programma / codici in sezioni / pezzi distinti in modo che ogni sezione possa affrontare un problema separato (Rif .: http://en.wikipedia.org / wiki / Separation_of_concerns )

ci sono molti vantaggi nel separare le preoccupazioni: uno non influirà su un altro e gli sviluppatori potrebbero lavorare su un'unità senza influire sul resto, ecc. ecc. ... MVC non è l'unico modello che segue il SoC, fondamentalmente, lo stesso OOP è un ottimo concetto per spezzare le cose in unità.

MVC / MV * sono molto utili quando si gestisce lo sviluppo relativo all'interfaccia utente, mentre al di sotto potrebbero esserci più modelli: fabbrica, singleton, facciata ecc. La maggior parte dei grandi progetti è costituita da più livelli che gestiscono aspetti diversi, ma l'interfaccia utente potrebbe non essere un must alcuni casi. Potresti vedere MVC molto, perché molti progetti hanno elementi dell'interfaccia utente.

quindi, mentre parliamo degli svantaggi di MVC, dipende davvero dai progetti che stai realizzando - ha un'interfaccia utente? richiede grande scalabilità / estensibilità? ha molte interazioni tra UI e behind-system? 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ù in generale - un modello di progettazione), dargli un contesto e pensare a complessità, scalabilità, testabilità, manutenzione, vincoli di tempo, ecc. ecc.