Per MVC o non MVC, questa è la domanda

Forse le tue applicazioni non sono molto grandi? Ricordo la prima grande app che ho co-scritto, consisteva solo di un gran numero di complessi plugin jQuery. Non c'era separazione di preoccupazioni, il codice era contorto, testarlo era quasi impossibile.

La prossima app che abbiamo scritto in Backbone. Ci ha dato una struttura di base su cui costruire. Ovviamente, Backbone ha introdotto la propria quota di problemi, ma ha risolto molto di più.

I nostri problemi riguardavano principalmente la reazione al modello & visualizzare le modifiche, abbiamo iniziato ad avere un gran numero di eventi e amp; gestori difficili da controllare. Anche allora, è stato un paradiso rispetto a quello che avevamo nella precedente app!

Abbiamo deciso di riscrivere l'app in AngularJS (preferenza personale, in questo paragrafo puoi sostituire Angular for Ember e gli argomenti probabilmente rimarranno). Ci ha permesso di rendere il nostro codice cliente del 40% più piccolo e molto più facile da mantenere; anche la testabilità era un vantaggio. Potremmo concentrarci maggiormente sulla logica dell'app che sulle modifiche manuali DOM.

Per riassumere, la mia esperienza è contraria alla tua. Mi piacerebbe pensare in modo simile a te in caso di siti semplici, dal momento che MVC introduce sempre alcuni standard e hai bisogno di determinate dimensioni dell'applicazione per usufruire dei vantaggi.

Dipende.

MVC è uno schema di progettazione visiva che semplifica la sostituzione della tecnologia dell'interfaccia utente durante la vita di un'applicazione.

Quindi devi chiederti:

Stai buttando fuori una piccola e sporca applicazione web a cui non tornerai mai? Se è così, allora non preoccuparti di MVC. Sul serio.

O stai scrivendo una sostanziale app Web che avrà un numero di visualizzazioni e potenzialmente persino una misura della logica che controlla il modo in cui un utente naviga tra le pagine? MVC inizia ad apparire molto più attraente in questo caso. Aumenta le tue possibilità di riutilizzare i controller e forse anche la possibilità di riutilizzare alcune delle pagine HTML parziali che scrivi.

Ma è più semplice prendere una decisione quando si osservano i due estremi. Se la tua app è da qualche parte nel mezzo, ti suggerirei di guardare al futuro. Se speri diventerà qualcosa o se saprai che continuerai a tornare a lavorare sull'applicazione, ti consiglio comunque MVC. Sì, c'è un costo per creare e mantenere l'impalcatura per supportare le cose. Ma quell'impalcatura aiuta a promuovere la separazione delle preoccupazioni. E quella separazione è ciò che renderà i tuoi cambiamenti futuri molto più facili da fare.

Penso che tu stia facendo la domanda sbagliata. Non è MVC o non MVC. Penso che una separazione delle preoccupazioni sia sempre una buona idea. Ma vuoi usare un framework per questo? Puoi anche scrivere MVC in javascript senza utilizzare framework per questo.

Quando si stanno facendo cose di backend in .NET, ad esempio, penso che il framework MVC sia ottimo. Tuttavia, il backend di un sito Web è senza stato, quindi la struttura è relativamente semplice rispetto al frontend. Non devi preoccuparti di callback o stato. Ecco perché i framework MVC one-size-fits-all sul back-end funzionano.

Il frontend è più complesso. La maggior parte dei framework javascript che ho visto stanno applicando un design particolare. La maggior parte dei javascript MVC non aggiunge comunque molto. La maggior parte di questi framework vincola automaticamente i tuoi eventi sul lato della vista, il che significa che hai meno controllo sui tuoi controller e le tue viste sono accoppiate al controller e nel corretto MVC dovrebbe essere il contrario. Un altro problema è che nel codice GUI un sacco di volte si ha un componente in un componente (forse in un altro componente) e si desidera astrarre e riutilizzare questi componenti. La maggior parte dei framework MVC consente solo uno strato di astrazione (che è il risultato del fatto che i controller non hanno abbastanza controllo).

Javascript è un linguaggio molto potente e puoi scrivere un grande codice senza un framework. Personalmente ho imparato di più sul libro Javscript: le parti buone e leggendo un po 'di schemi di design javscript.

Scrivo tutte le mie applicazioni in Delphi (come uno strato di astrazione), non voglio e non hanno bisogno di Javascript o HTML, sebbene il framework li generi per me. Programmiamo l'astrazione dei livelli da quando abbiamo lasciato l'assemblatore.

Ho anche scritto su questi tempi di gioco, di applicazioni lego.