Quando favorire i WebForm ASP.NET su MVC

So che Microsoft ha detto

ASP.NET MVC non sostituisce WebForms.

E alcuni sviluppatori affermano che WebForms è più veloce da sviluppare rispetto a MVC. Ma credo che la velocità della codifica si riduca al livello di comfort con la tecnologia, quindi non voglio risposte in tal senso.

Dato che ASP.NET MVC offre agli sviluppatori un maggiore controllo sulla loro applicazione, perché WebForms non è considerato obsoleto? In alternativa, quando dovrei favorire WebForms su MVC per i nuovi sviluppi?

Webforms vs. MVC sembra essere un argomento caldo in questo momento. Tutti quelli che conosco promuovono MVC come la prossima grande cosa. Dai miei piccoli dilettanti in esso, sembra ok, ma no non credo che sarà la fine dei moduli web.

Il mio ragionamento e il ragionamento sul perché i moduli web vengano scelti su MVC, hanno più a che fare con una prospettiva commerciale piuttosto che con ciò che è meglio dell'altro.

Il tempo / denaro sono i motivi principali per cui i moduli web vengono scelti su MVC.

Se la maggior parte del tuo team conosce i moduli web e non hai il tempo di aggiornarli su MVC, il codice che verrà prodotto potrebbe non essere di qualità. Imparare le basi di MVC, poi saltare e fare quella pagina complessa che devi fare sono cose molto diverse. La curva di apprendimento è alta, quindi è necessario tenerne conto nel budget.

Se hai un sito Web di grandi dimensioni scritto tutto in moduli Web, potresti essere più propenso a creare nuove pagine in moduli Web in modo da non avere due tipi di pagine molto diverse nel tuo sito.

Non sto dicendo che è un approccio tutto o niente qui, ma rende il tuo codice più difficile da mantenere se c'è una divisione di entrambi, specialmente se non tutti i membri del team hanno familiarità con MVC.

Di recente la mia azienda ha realizzato tre pagine di test con MVC. Ci siamo seduti e li abbiamo progettati. Un problema che abbiamo riscontrato è che la maggior parte dei nostri schermi ha la funzionalità Visualizza e modifica nella stessa pagina. Abbiamo finito per aver bisogno di più di un modulo nella pagina. Nessun problema, tranne che non useremmo la nostra pagina principale. Abbiamo dovuto rinnovarlo in modo che sia le pagine dei moduli web sia le pagine MVC potessero utilizzare la stessa pagina principale per un aspetto comune. Ora abbiamo un ulteriore livello di nidificazione.

Avevamo bisogno di creare una struttura di cartelle completamente nuova per queste pagine in modo che seguisse la corretta separazione MVC.

Ho sentito che c'erano troppi file per 3 pagine, ma questa è la mia opinione personale.

A mio avviso, sceglieresti i moduli web su MVC se non hai il tempo / denaro da investire nell'aggiornamento del tuo sito per utilizzare MVC. Se segui un approccio a metà percorso, non sarà migliore dei moduli web che hai adesso. Peggio ancora, potresti anche impostare questa tecnologia per il fallimento della tua azienda se è incasinata, dal momento che i dirigenti potrebbero vederla come qualcosa di inferiore a ciò che sanno.

Ho sviluppato applicazioni ASP .Net WebForms per 3 anni e dopo un giorno di esecuzione di un tutorial MVC sono stato venduto. MVC è quasi SEMPRE la soluzione migliore. Perché?

• Il ciclo di vita della pagina è più semplice ed efficiente
• Non esistono controlli oltre ai controlli html. Non è necessario eseguire il debug dell'output per vedere cosa sta generando ASP .Net.
• ViewModels ti dà immensa potenza e elimina la necessità di eseguire l'associazione di controllo manuale ed elimina molti errori relativi all'associazione.
• Puoi avere più moduli in una pagina. Questa era una grave limitazione di WebForms.
• Il web è apolide e MVC abbina l'architettura del web più da vicino. Webforms introduce lo stato e i bug che hai con esso introducendo ViewState. ViewState è automatico e funziona in background, quindi non si comporta sempre nel modo desiderato.
• Oggigiorno le applicazioni Web devono funzionare con Ajax. Non è più accettabile caricare la pagina intera. MVC rende ajax molto meglio, più facile e più efficiente con JQuery.
• Poiché puoi avere più moduli su una pagina e poiché l'architettura è guidata da chiamate agli URL, puoi fare cose funky come Ajax caricare un modulo diverso, come un modulo di modifica nella tua pagina corrente usando JQuery. Una volta che ti rendi conto di ciò che ti permette di fare, puoi fare cose incredibili facilmente.
• ASP .Net WebForms non è solo un'astrazione su html, è estremamente complessa. A volte potresti avere un bug strano e lottare con esso per molto più tempo del necessario. In molti casi potresti effettivamente vedere cosa stava facendo di sbagliato ma non sei in grado di fare nulla al riguardo. Finisci per fare strane soluzioni.
• WebForms non è una buona tecnologia per i progettisti. Ai designer spesso piace lavorare direttamente con HTML. In MVC è una vista, in WebForms è mezza giornata di lavoro.
• Poiché la piattaforma Web si sta evolvendo rapidamente WebForms non continuerà. Non è a conoscenza di nuovi tag o funzionalità di HTML5, renderà comunque le stesse cose a meno che tu non ottenga (spesso) costosi controlli di terze parti o aspetti che Microsoft rilasci un aggiornamento.
• I controlli in WebForms ti limitano in molti modi. In MVC puoi semplicemente prendere una libreria JQuery e integrarla nei tuoi modelli.

So che alcuni dei problemi di cui sopra sono stati risolti in una certa misura con l'evoluzione di WebForms, ma questa è stata la mia esperienza originale. Tutto sommato, troverei estremamente difficile trovare un business case per WebForms a meno che un progetto non lo stia già utilizzando.

Ho mandato un'e- mail a Scott Guthrie , un esperto MVC di Microsoft. E probabilmente l'uomo più qualificato per rispondere a questa domanda. È stato così gentile da rispondere:

"Diversi clienti cercano approcci di programmazione diversi e amano molto WebForms e pensano che sia grandioso. Altri amano MVC e pensano che sia grandioso. Ecco perché stiamo investendo in entrambi."

Quindi, per me questo dice che non è un problema tecnico. È più un "problema", se vuoi. Una delle preferenze personali. Questo è in linea con quanto molti di voi hanno detto.

Grazie per tutte le risposte

Questa è una domanda viziata con molte risposte ma nessuna aveva la risposta che mi sarei aspettato di essere elencato.

La risposta breve è:

• Utilizzare ASP.NET MVC se si intende creare correttamente un'applicazione Web con convenzioni di programmazione moderne e schemi di utilizzo industriale per la piattaforma ASP.NET. Sul lato negativo ci si aspetta che tu sappia come funzionano le risorse HTML e lato client (Javascript, CSS), oltre ad accelerare la mentalità di programmazione MVC che ha una ripida curva di apprendimento ma raggiunge una fine improvvisa una volta afferrata.
• Utilizzare i moduli Web ASP.NET se si sta utilizzando o si desidera utilizzare un approccio basato su GUI , RAD (Rapid Application Development) , drag-and-drop per la prototipazione di qualcosa molto rapidamente, ovvero il comportamento della griglia di dati / pulsante cablato all'interno di 15 minuti e la soluzione non intende essere qualcosa di supportato dagli sviluppatori. In alternativa, utilizzare i moduli Web ASP.NET se si dispone di un background nello sviluppo della GUI o di Windows Form e si desidera trasferire le proprie conoscenze sul Web.

Ma per vederlo correttamente, devi capire la storia di ciascuno.

ASP.NET Web Forms è stata la risposta di Microsoft a coloro che avevano sviluppato applicazioni Web dinamiche utilizzando i controlli ActiveX di Visual Basic 6, le DLL VB6 sul server e ASP Classic. All'epoca, lo sviluppo web con questi strumenti Microsoft era un vero casino. Insieme all'intero .NET Framework che è stato l'output di Microsoft, essenzialmente tornando al tavolo da disegno su come eseguire una programmazione aziendale produttiva sullo stack di Windows, ASP.NET Web Forms era, a suo tempo, sorprendente e bello.

L'intero approccio è stato quello di offrire agli sviluppatori il meglio di entrambi i mondi di qualcosa di molto simile allo sviluppo di applicazioni Windows, ma con la potenza dei servizi Internet. L'idea era che, proprio come con un "Modulo" VB6 / WinForms (una finestra), anche una pagina Web è un modulo (proprio come una finestra, vedi) , e su quel modulo è possibile trascinare e rilasciare etichette, caselle di testo, griglie di dati, pulsanti e altre cose a cui gli sviluppatori della GUI di VB / WinForms erano abituati.

Per fare in modo che un pulsante faccia qualcosa, dopo averlo trascinato, fai doppio clic su di esso nel designer e fai esplodere nell'editor di codice, dicendo al modulo cosa fare quando si verifica quell'evento "clic". Questo è esattamente il modo in cui gli sviluppatori della GUI di Windows hanno creato software utilizzando gli strumenti della GUI di VB6 e strumenti concorrenti, tranne ora che il codice è in esecuzione sul server! Wow!

Questa era la tecnologia del 2002. Incredibile e bello ai suoi tempi come risposta a soluzioni GUI abilitate a Internet per lo sviluppo di RAD , ha portato un senso di potenza in un mondo disordinato di sviluppatori software che avevano obiettivi aziendali che dovevano raggiungere.

Sfortunatamente, questo modello di programmazione enfatizza così tanto la metafora della programmazione della GUI di Windows che porta con sé l'onere dei suoi dettagli di implementazione necessari, tutto il bagaglio ingombrante necessario per ospitare i cicli di vita degli eventi e nascondere i brutti dettagli del semplice HTML e script generato da questi componenti e controlli con trascinamento della selezione. E alla fine della giornata, gli sviluppatori che supportano applicazioni reali dovevano inevitabilmente scavare in profondità in questi componenti o scrivere i propri, e di conseguenza avrebbero combattuto battaglie con questa infrastruttura, battaglie che avrebbero lasciato dietro pile su pile di motoscafo, capelli strappati e lacrime.

Eseguire il backup. Lavati le mani. Esaminiamo di nuovo il problema aziendale. Quali sono i nostri obiettivi aziendali?

Dobbiamo creare e gestire applicazioni Web . I nostri vincoli sono che abbiamo il World Wide Web, che si trova su HTTP, HTML, Javascript e CSS, e sul server abbiamo regole di business, database e una manciata di grandi linguaggi di programmazione (ad esempio C #). Abbiamo davvero bisogno di questa metafora della GUI di Windows per guidare la nostra metodologia di sviluppo? Perché non possiamo concentrarci solo sui problemi dell'applicazione e eliminare le metafore della GUI?

È qui che entra in gioco ASP.NET MVC. È iniziato da una ribellione di sviluppatori che si chiamavano "Alt.Net" e che volevano tornare ai principi di sviluppo software corretti e puri. Niente più confusione, concentrati solo sugli obiettivi aziendali e sulle migliori pratiche software.

Ciò che questo si traduce in questo caso è:

1. Separazione delle preoccupazioni . Ad esempio, un componente di dati non ha bisogno di sapere come verranno resi i suoi dati, né dovrebbe visualizzare il markup gravato con i dettagli di configurazione della connessione al database e in questo modo uno sviluppatore può concentrarsi sulla sua area di interesse durante la modifica e codice di prova.
2. Esposizione e pieno supporto per l'esposizione alla nitidezza di HTML e risorse correlate . In Web Forms, l'HTML è nascosto, gli sviluppatori sono scoraggiati dal preoccuparsi di ciò. In ASP.NET MVC, gli sviluppatori sono piuttosto incoraggiati a gestire questi dettagli; in effetti è una necessità. Il vantaggio qui è che lo sviluppatore può imparare nuovamente ad apprezzare la semantica pulita di HTML, CSS e script e lavorare con esso piuttosto che contro di esso.
3. Testabilità di oggetti business . I controller e i modelli sono molto più adatti per i test delle unità programmatiche, in modo che le implementazioni possano essere convalidate per raggiungere gli obiettivi aziendali e che le modifiche possano essere verificate e che non si interrompano. Con i Web Form era difficile testare poiché i componenti non erano progettati per essere testati individualmente e l'intero output di sviluppo ruotava attorno ai moduli di pagina e ai loro cicli di vita degli eventi con la confusione della logica aziendale e della logica di presentazione profondamente intrecciate.

Si noti che HTML è già un linguaggio di markup di altissimo livello, così come Javascript è un linguaggio di programmazione di alto livello. L'intera storia sarebbe stata diversa se avessimo a che fare con il linguaggio dell'Assemblea e C.

Espandendo su # 2, quindi, un altro obiettivo di ASP.NET MVC è quello di consentire agli sviluppatori di organizzare i dettagli front-end della parte 'view' delle loro soluzioni e sfruttare la ricca base su cui il resto del settore ha costruito la piattaforma client front-end.

Scoprirai che gli sviluppatori ASP.NET MVC si sentono a casa utilizzando ricche librerie Javascript e tecniche di templazione lato client senza combattere con l'architettura lato server. Questo non era originariamente il caso dei moduli Web ASP.NET, poiché i moduli Web non vogliono che tu guardi l'HTML o lo script, tranne se devi davvero , nel qual caso, fai attenzione, non è per i deboli del cuore.

Sono una conversione completa e totale in ASP.NET MVC e non ho guardato indietro, che ha detto che devo ancora mantenere diverse app WebForms molto grandi. Ecco la mia opinione su di esso:

WebForms Usali
quando hai qualche serio sollevamento pesante a che fare con le griglie. I controlli della griglia sono davvero molto utili quando si dispone di un set di dati semplice che si adatta perfettamente in un formato tabulare e si desidera fornire agli utenti un modo semplice per aggiornare i record. Sì, lo so che MVC 4 ha una lista Ajax davvero elegante che puoi usare e che funziona alla grande ma, nella nostra attività spesso abbiamo bisogno di far funzionare qualcosa ieri e buone griglie vecchio stile funzionano alla grande e gli utenti sono felici di esserlo in grado di passare da una griglia all'altra con gioia. Per me questa è davvero la cosa migliore di WebForms per me; ma, come Ryansottolineato WebForms può essere un gran casino perché stai giocando entrambi i lati del recinto da un file code-behind elegante. Può essere sia una rosa che una spina allo stesso tempo per mantenere tutte le tue cose di tipo controller mescolate con le tue viste.

MVC
Utilizzalo quando vuoi davvero creare il tuo e hai l'opportunità di avviare un'applicazione da zero. Avere un'applicazione MVC chiaramente definita è un po 'più impegnativo per iniziare, ma i suoi vantaggi in termini di manutenibilità superano i costi iniziali di installazione. Se vuoi fare interazioni Ajax interessanti, preferisci scrivere il tuo modello con codice, come url e percorsi puliti ed essere in grado di controllare l'intero flusso della tua app, questa è sicuramente la strada da percorrere. All'inizio ci vuole un po 'per abituarsi, ma penso che sia l'opzione migliore per le app greenfield.

In conclusione, per me, si tratta di griglie e! Griglie. :)

La mia esperienza:

• Ha scritto progetti CakePHP per un anno.
• Ha completato un progetto Webforms di medie dimensioni per sei mesi.
• Ha lavorato a un progetto Windows Form per tre anni.

Dopo quell'esperienza, ho provato a scrivere un'altra app usando i moduli web e sono rimasto frustrato dopo aver lottato per circa un giorno con il modo in cui i moduli web tentano di proteggere lo sviluppatore dalla realtà che stanno sviluppando un'applicazione che utilizza HTML, JavaScript e CSS.

Ho quindi provato MVC, e avendo un controllo più diretto sull'output (e una certa esperienza con il paradigma MVC di CakePHP) sono stato in grado di completare quella semplice app esattamente come la desideravo in circa 1/2 al giorno.

La disponibilità di potenti framework dell'interfaccia utente come jQuery elimina molto l'interesse di rinunciare al controllo diretto dell'output a favore dell'utilizzo di componenti dell'interfaccia utente spesso ingombranti pre-costruiti.

Preferisco i moduli web perché il mio background è lo sviluppo di Windows.

La velocità di sviluppo è un problema chiave e posso facilmente passare un problema a qualcuno in India per risolvere durante la notte con i moduli, inoltre, se ho un problema di velocità su una pagina, un libro davvero buono sulla velocità di asp.net è utile (Rick Kiessig è l'uomo).

webforms è per persone ex windows mvc è per persone web

ma, nel mondo moderno, dove Rick ha scritto un libro fantastico, con i server che aumentano di velocità quotidianamente e programmatori economici in India, beh, i moduli web hanno il vantaggio

Il mio 2 centesimi è di utilizzare sempre ASP.NET MVC per nuovi progetti se ne hai la possibilità. A mio avviso, i moduli web non sono un buon modo per sviluppare app Web, punto.

Penso che sottrarre REST di base sia negativo, l'intero modello di postback è negativo, il modo in cui html / css viene distribuito facendo affidamento sull'editor GUI è cattivo, l'enfasi su cose come maghi e GUI per impostare roba è cattiva, gli URL sono cattivi.

Ho letto tutte le risposte e sento che la mia esperienza personale aggiungerebbe qualcosa alle risposte sopra.

3-4 anni fa, ho sviluppato 2-3 progetti di siti Web utilizzando Webforms. In quel periodo, MVC non era nei paraggi o non ne avevo sentito parlare. Lo sviluppo è stato naturalmente (venivo dallo sviluppo di moduli Win senza precedenti esperienze di sviluppo Web) per me, poiché non ho bisogno di imparare l'HTML nei dettagli e i controlli web mi hanno aiutato molto (molto, ha semplificato la vita) .

Ora, dopo tutto quel tempo, non stavo lavorando a nessun progetto web fino a poco tempo fa e semplicemente costruendo alcune applicazioni Windows usando WPF.

Pochi giorni fa ho avuto un'idea per un sito Web e ho pensato di svilupparlo: questa volta a MVC (dal momento che si parlava ovunque, inoltre avevo bisogno di imparare, quindi ho scelto MVC). Il progetto è ancora in fase di sviluppo, poiché sto ancora imparando e costruendo insieme.

Quindi, le differenze chiave che trovo in b / n le due sono le seguenti: -

• Per qualcuno proveniente dallo sviluppo di Windows, i moduli Web saranno sempre favorevoli. La curva di apprendimento di Asp.net per uno sviluppatore di Windows è un po 'ripida

• Per qualcuno che viene dallo sviluppo web in qualche altra tecnologia, MVC sarà favorito dal momento che prende in giro l'ultimo di tutti.

• Lo sviluppo è più semplice e più pulito in MVC se hai una buona conoscenza di HTML e CSS

• La distribuzione è ancora un problema. Nei moduli Web è sufficiente copiare e incollare. Ma questo richiede alcune cose da fare.

In breve, rimarranno entrambi per un po '.

Non ho ancora visto questa considerazione avanzata tra le 15 risposte esistenti a questa discussione, ma penso che valga la pena prendere in considerazione.

Dalla mia esperienza Web Forms è più simile a Win Forms e WPF di MVC. Detto questo, penso che si potrebbe prendere in considerazione la scelta di Web Forms quando il team ha la maggior esperienza in quel tipo di tecnologia o quando il progetto Web Forms fornirà un'interfaccia sullo stesso set di dati di un Win Forms esistente (o sviluppato contemporaneamente) o Progetto WPF. Ciò consente agli sviluppatori di attraversare più facilmente i progetti, poiché la logica dell'applicazione può essere abbastanza simile tra i due.

Come hanno sottolineato altre risposte, lo sviluppo sul framework MVC è più simile allo sviluppo web in Ruby, PHP, Python ecc. Rispetto alle sue controparti Microsoft; quindi, naturalmente, la scelta di MVC può essere influenzata dall'esperienza dei team in quelle aree, insieme ai fattori presentati in altre risposte.

La nostra ragione per non andare a MVC qualche anno fa era che era una tecnologia immatura di Microsoft. Negli ultimi anni siamo ora su una versione più matura (4) e MS sembra aver capito dove stanno andando con questo. Tuttavia, siamo ancora riluttanti a sviluppare le principali app LOB utilizzando MVC poiché le funzionalità che vogliamo utilizzare nella versione 4 richiedono un server Windows 2012 (re socket Web tramite IIS8). Ritengo che tra un altro anno saremo maggiormente in grado di accettare MVC poiché si spera che saranno disponibili più controlli da parte di terzi, la tecnologia si sarà stabilizzata e avremo le infrastrutture per supportarlo.

Questa decisione dipende dalle tue preferenze, dai tuoi requisiti o anche dalla tua conoscenza ed esperienza.

Il tempo per l'apprendimento dell'apprendimento MVC o il tempo per ottenere una consegna. Tutte queste cose contano di scegliere l'uno o l'altro approccio.

Non è che uno sia migliore di un altro, semplicemente sia l'approccio che i quadri hanno pro e contro.

Personalmente preferisco MVC 3, ti consiglio di provare la tua esperienza, ma devo dire che il programma in MVC è un modo pulito, divertente, flessibile, estensibile, sicuro e strutturato.

Saluti,

L'unico motivo per cui sceglierei i Web Form invece di MVC è perché hai molti più controlli UI di terze parti per Web Form rispetto a MVC. Ho scelto MVC perché ho lavorato troppo con WebForms e voglio lavorare con qualcosa di nuovo / nuovo, ma ancora da MS shop :)

Fondamentalmente, nulla ti impedisce di disattivare il viewstate in WebForms e utilizzare ViewModels e if / for loop invece di binding del modello e controlli lato server.

È questo WebForms o codice MVC:

<% foreach (var item in Model.Items) { %>
<p><%: item.Name %></p>
<% } %>

L'unica limitazione che ho riscontrato in WebForms è che se si utilizza Iniezione dipendenze / Inversione del controllo, non è possibile eseguire l'iniezione del costruttore poiché le pagine WebForms devono avere un costruttore senza parametri, quindi è necessario utilizzare l'iniezione di proprietà. È davvero un grosso problema?

ASP.NET MVC è davvero una risposta a Ruby, e il modo migliore, nuovo e di tendenza (IMO) di disaccoppiare il browser (client) dal server il più possibile.

ASP.NET Webforms ti dà molto controllo sul client dal lato server, con accesso diretto praticamente a tutto. Fondamentalmente la tua vista e il tuo controller sono la stessa cosa, il che ti dà molta potenza e il più delle volte un sacco di casino.

ASP.NET MVC separa la vista e il controller staccando l'accoppiamento stretto tra un file .aspx e il file .aspx.cs che li accompagna nei moduli web.

In sostanza, la differenza sta nel fatto di avere molto di più (in genere tutti) dell'elaborazione per visualizzare i dati nel file di visualizzazione e di lasciare la logica aziendale e il resto nel controller, mantenendoli entrambi più puliti per convenzione, ma anche con meno accesso a ciascuno diverso dai moduli web consente.

A mio avviso, sono abbastanza correlati e hanno all'incirca le stesse capacità che dovrebbe scendere alle preferenze.

Un grande sviluppatore WebForms può produrre un prodotto altrettanto potente come un grande sviluppatore MVC. Ma il grande sviluppatore di WebForms che cerca di costringersi ad adottare MVC sta per arrivare corto. Lo stesso vale per un grande sviluppatore MVC che offre a WebForms una possibilità.

Non sono entità completamente separate e finché Microsoft continua a supportare entrambi, credo che continuerai a vedere un gruppo misto di sviluppatori eccezionali per ciascuno.

Si tratta solo di scelta personale, supponendo che siamo tutti competenti con la tecnologia che utilizziamo. Sto usando l'approccio di progettazione WebForms da molti anni e devo dire che l'unico aspetto negativo è che a causa del suo approccio semplicistico, molte persone non si prendono il tempo per scoprire le sue vaste capacità.

Di recente ho usato MVC per completare un progetto e, sebbene mi piaccia molto l'approccio alla progettazione per lo sviluppo di applicazioni (che ti dà più controllo, URL puliti, SOC, ecc.), In realtà non c'è molto che fornisce, che WebForms non può. In effetti, l'emergere di jQuery e del suo funzionamento con WebForms (così come MVC) ha reso questi argomenti meno problematici. E quando le persone parlano della separazione delle preoccupazioni come un vantaggio che MVC ha rispetto a MVP, chiedo loro quanto sanno della programmazione orientata agli oggetti e quanto mettono in pratica il principio di astrazione e polimorfismo.

Attualmente mi sento a mio agio con entrambe le tecnologie e scelgo in base alla situazione. Francamente, dipende da te, ma la verità rimane che non tutti si prendono il loro tempo per imparare in profondità di cosa è capace una particolare tecnologia.

Di fronte a un problema di programmazione, cerco spesso risposte sul Web. Webforms ha tonnellate di informazioni / componenti per fare praticamente qualsiasi cosa. In MVC a causa di un minor numero di fonti online e gli strati di astrazioni necessari per far funzionare qualcosa ha posto un limite alle cose che avrei potuto fare una volta. MVC total uccide la mia produttività come sviluppatore mentre con Webform non lo è. Quindi per ora mi attengo ai moduli web fino a quando MVC non è abbastanza maturo per sostituirlo.

Bene, i Web Form hanno più risorse di apprendimento disponibili (semplicemente per il fatto che è più vecchio) e quindi i nuovi programmatori che non sono "al corrente" avranno maggiori probabilità di trovare informazioni su questa tecnologia più vecchia rispetto alle cose più recenti come MVC .

I programmatori senior / esperti sono più anziani e saranno più competenti nella tecnologia più vecchia a causa del fatto che hanno programmato in esso più a lungo di quanto non abbiano in quella più recente.

A meno che tu non possa spendere i soldi e gli sforzi per rendere i tuoi ragazzi più esperti in MVC come lo sono nelle applicazioni WebForms, indubbiamente proverai a trattenere l'aggiornamento alla nuova piattaforma il più a lungo possibile.

Quindi presenta diversi problemi logistici: i vantaggi di MVC superano i costi in termini di minore qualità e tempi di implementazione? Se avessi un sito interamente scritto in WebForms, varrebbe la pena lo sforzo e il denaro per integrare MVC in esso?

Come affermato da un commentatore precedente, MVC ti impedisce anche di raggiungere lo stesso livello di interfaccia con il controller che potresti avere con WebForms. Sebbene io sia tutto per il lato "Impedisci all'utente di riempire le cose / apprendere", può comunque essere irragionevolmente problematico per i team implementare / implementare un programma che si attacca fanaticamente a quel paradigma per tutto ciò che scrivono.

Penso che il divario tra queste due tecnologie non sia ampio come una volta.

• I moduli Web possono utilizzare il motore di routing utilizzato da MVC (o qualcosa di molto simile).
• Il gestore degli script può combinare gli script, caricarli da una CDN e persino ritardare il caricamento degli script.

Per rispondere direttamente alla tua domanda, penso che dipenda dalle preferenze e / o dal progetto. Entrambi adottano un approccio significativamente diverso allo sviluppo. Personalmente ho lavorato per spostarmi verso MVC, ma mi piace ancora lavorare con i Webform. Penso che la risposta a qualsiasi cosa dovresti usare MVC o Webforms è che tu decida attraverso entrambe le tecnologie.