Clean, Modular Code vs MV * Frameworks [closed]

Il codice pulito trionfa sempre su tutti i modelli architetturali, nel senso che se mi dai la scelta di un codice pulito e comprensibile che non sia scritto in modo MVC o un codice contorto e sgradevole che si adatti in un modo MVC ... Prenderò il ex.

ci sono degli svantaggi in queste cose. John Gossman ha detto di MVVM (la versione model-view-viewmodel di WPF di MVC) che è eccessivo per i piccoli progetti e la complessità della sua progettazione può essere eccessiva per progetti di grandi dimensioni. Ha anche detto che l'utilizzo delle risorse può renderlo inadatto anche per progetti di medie dimensioni:)

Quindi la separazione del codice in una presentazione, i livelli logici e di dati in qualche modo è una buona cosa, rende il tuo codice più semplice da scrivere e ti consente di gestire ogni sezione separatamente. Se ciò significa che devi utilizzare un framework MVC esistente è un altro aspetto, tuttavia, come Gossman ha detto, i tuoi requisiti esatti per il tuo progetto potrebbero essere abbastanza diversi da quelli definiti per un framework MVC per rendere quel framework più problematico del suo valore. Come sempre, non c'è un proiettile d'argento.

Il fatto è che se scrivi codice pulito e modulare in un'applicazione complessa (intendo l'applicazione con molte funzionalità dell'interfaccia utente, poiché la domanda riguardava in particolare i framework JS e MV *), ti renderai conto, alla fine, che sei facendo un'applicazione in stile MV *. Potrebbe avere un'altra implementazione e aspetto del codice, ma sarà MV * -application. Non potrei scommettere qui, ma sono sicuro al 95% che sarà quello.

L'architettura MV * non è un tipo di moda, o una caratteristica killer, o qualcosa che potrebbe essere buttato fuori. È un modo pragmatico per organizzare ricche applicazioni dell'interfaccia utente per affrontare la complessità dei programmi moderni.

Vedo i seguenti motivi per l'utilizzo di tali framework:

1. Non tutti le strutture codificano il codice per impostazione predefinita. I quadri impongono la struttura in una certa misura. Questa estensione è variabile in base alla quantità di scaffold che forniscono. Troppa scaffolding di solito si traduce in una curva di apprendimento più ripida.

2. I framework generalmente incapsulano schemi progettuali / di programmazione dall'esperienza collettiva di una comunità più ampia, quindi in alcuni casi ci sarà già una struttura lì dentro, mentre costruirai e rifattori.

3. La maggior parte degli sviluppatori vanno e vengono, utilizzando framework popolari / standard rende più semplice per gli sviluppatori che lo sviluppatore originale comprendere la struttura. I buoni framework sono ben documentati e le community attive possono chiedere aiuto.

4. Quando ti sposti dal progetto, molto probabilmente copia / incolla il codice dal precedente progetto che ora richiedi in un nuovo progetto. Se utilizzi un framework anche se è il tuo framework MV *, devi solo importare e includere questo framework ogni volta.

Ci sono una serie di elementi che devono essere risolti dalla tua domanda. Sto per dire MVC quando quello che intendo è " MVC e tutte le varianti correlate".

I've been hearing a-lot about the "new" MV* frameworks.

Come dovresti; c'è un numero di vantaggi (e svantaggi) nell'utilizzo di un framework MVC o simili.

Ricorda inoltre che MVC è presente negli anni '70 e che è stato reso popolare con l'uso di SmallTalk. Consulta i vari saggi di Martin Fowler sulle architetture della GUI per ulteriori informazioni.

but I much prefer to write clean, modular code in raw JavaScript

Quindi dovresti vedere il fascino di MVC allora. : -)

MVC è stato creato per aiutare a far rispettare l'esatta cosa che stai proclamando di volere all'interno del tuo codice. Cambiamenti (viste) dell'interfaccia utente. La logica per guidare le modifiche dell'interfaccia utente (controller *). Le origini dati e i meccanismi di accesso (modello) cambiano. MVC è stato progettato per incapsulare il cambiamento e fornire le migliori probabilità di migrazione di ciascun componente alla successiva incarnazione dell'applicazione. Separando gli strati in singoli componenti, il rischio di cambiamento è ridotto al minimo.

_{* Per Controller , intendo l'uso moderno del termine non l'uso originale dai giorni SmallTalk. E se ciò non ha senso, quindi ignorare questo sidenote.}

Given a methodical/structured/SOLID approach to writing a JavaScript application, where OOP, SOC, SRP and other design principles are adhered to, wouldn't the usage of MV* frameworks be superfluous?

Forse è superfluo, forse non lo è. Quanto è grande la tua applicazione? Quanto è devoto il tuo team a "fare la cosa giusta?" Quanto bene il tuo team comprende il dominio e dove dovrebbero trovarsi le responsabilità all'interno di ogni singola classe?

Questo è un sacco di dipendenze da altri che stai introducendo lì. Certo, il tuo codice è perfetto e non commetterai mai un errore di progettazione. Ma come riuscirai a proteggere il progetto dalla fallibilità umana degli altri? Come riuscirai a proteggere il progetto dalle complessità di scala? Una manciata di punti di vista non è nulla da tenere nella tua memoria. Ma per quanto riguarda le centinaia?

MVC fornisce una struttura per evitare alcuni di questi problemi.

Ma allo stesso tempo, MVC non è un proiettile d'argento. Ecco alcune delle critiche valide contro di esso.

• Tende ad essere pesante per l'implementazione. Dove avresti potuto ottenere con 1 lezione, ora ne avrai tre. Sui progetti più piccoli, hai ragione a mettere in discussione i vantaggi di MVC.

• Può essere frustrante rimanere all'interno della struttura di MVC. C'è sempre la tentazione di lasciare il codice del controller sanguinare nella vista, o lasciare che la vista acceda direttamente al modello. Dopo aver scritto la tua ennesima funzione wrapper, ti chiedi perché lo stai facendo.

• MVC presume che la tua app vivrà per sempre e cambierà le tecnologie. Se non cambi mai l'interfaccia utente, l'origine dati o la logica aziendale, hai perso tempo a incapsulare questi livelli in previsione del cambiamento.

In sintesi, MVC è uno strumento come qualsiasi altro. La sua longevità e il risorgere della consapevolezza dimostrano quanto sia stato prezioso. Ma non è un proiettile d'argento, non una panacea per tutti i disturbi di programmazione. Comprendilo e usalo (o no!) Come appropriato per i tuoi progetti.