L'analogia Rolls-Royce / Toyota è terribilmente imperfetta e fuorviante. Uno (ASP.NET MVC) non è semplicemente una versione più elaborata o più costosa dell'altro (WebForms ASP.NET). Sono approcci molto diversi alla creazione di applicazioni Web utilizzando ASP.NET.
Per me, la più grande differenza architettonica tra MVC e WebForms è il modo in cui funzionano con l'ambiente stateless del Web: WebForms lavora duramente per creare una serie di astrazioni che nascondono la natura stateless della programmazione Web, mentre MVC abbraccia l'ambiente senza stato e lavora con esso.
Ogni approccio ha i suoi vantaggi e svantaggi, ma mi piace davvero come la creazione di siti Web con MVC sia molto più naturale di WebForms (con il suo strato su strato di astrazioni leaky ).
Vecchia domanda ma merita una risposta più dettagliata nel caso in cui qualcun altro là fuori stia ancora avendo un dilemma su di esso.
In definitiva, webforms è una soluzione thin client con la quale si intende premere un gruppo di pulsanti piuttosto belli e la roba front-end (client) è costruita per te. Se si dispone di persone che sanno come farlo girare in webform e non ci sono assolutamente problemi di manutenibilità / modificabilità e il sito è completamente a breve termine e usa e getta, non c'è assolutamente nulla di sbagliato in questo approccio. È possibile imparare come fare le proprie cose, ma in questo caso richiederebbe conoscere sia le webform che le webforms cercano di proteggere gli sviluppatori di app .NET da e tutte le cose di webforms che rende la maggior parte degli sviluppatori di web sul lato client vogliono uccidere Microsoft ingegneri responsabili.
Nel 99,5% di tutti gli scenari di altri casi d'uso, abbiamo smesso di cercare di nascondere il web dagli sviluppatori di app perché, in realtà, se vuoi scrivere app web, stai molto meglio imparando effettivamente come funziona il web. L'ironia delle soluzioni thick vs thin client è che inevitabilmente l'approccio thin client porta inevitabilmente alla rovina del tuo front end ed è tutt'altro che performante. Ancora più importante, queste soluzioni hanno sempre reso le cose inflessibili come l'inferno per le persone che sanno effettivamente cosa stanno facendo e non vogliono essere vincolati dal framework in vigore.
Non c'è nulla di così insensato come prendere qualcuno che sa tutto su CSS, JavaScript, HTML, XHR e renderli completamente inutili bloccandoli in ogni fase del cammino con un framework che ...
Cancella tutti i tag di script "non necessari" nei tag head per impedirti di rovinare le dipendenze dello script. (meglio lasciare che un "gestore di script" gestisca ciò che fa per te) Certo, nessuno li ha messi lassù al giorno d'oggi se sanno cosa stanno facendo ma questo è solo incasinato.
Insiste nel racchiudere tutto l'HTML in un tag ginormous form. HTML non consente i moduli all'interno dei moduli in modo che tu faccia il modulo webforms in nessun modo.
Si crea come un "ciclo di vita" di 18 passaggi per ciò che realmente dovrebbe ridursi a reagire agli eventi dell'interfaccia utente interagendo con il browser per inviare messaggi al server e quindi reagire quando il server risponde. Estrarre quel processo con un enorme mucchio di spazzatura non ha mai avuto bisogno di succedere (e per essere onesti, MS non è l'unico idiota che ha provato a farlo).
In realtà fa tutto il possibile per ostacolare l'utilizzo di soluzioni non webform ai problemi. Esempio: quando ero un dev del lato cliente più giovane ho passato un giorno intero a trovare un modo per fare in modo che un pulsante di invio nella parte superiore della pagina attivi un pulsante di invio nella parte inferiore di una pagina (presumo dovuto a quell'unico cosa di forma gigante). Normalmente ci sarebbero voluti 5 minuti, ma dopo alcune ore di reverse engineering del webforms JavaScript responsabile, ho scoperto che erano tra le altre cose l'impostazione di una proprietà che non sapevo nemmeno al momento che ti dice quale sia l'ultimo elemento del form da avere il focus era che quando veniva cliccato un pulsante di invio, solo il pulsante Microsoft Submit (tm) ufficiale avrebbe funzionato per quanto riguarda l'attivazione di un gestore Microsoft Submit (tm) ufficiale.
Quindi no, Rolls-Royce contro Toyota, è completamente irragionevole. Direi di più, una Hyundai perfettamente ragionevole che paghi troppo per contro una Pinto con Microsoft progettata con un sistema di bordo che fa automaticamente virate di 90 gradi quando scopri che hai comprato gas o petrolio da qualcuno che non sia Microsoft e viene rilevato un comodo muro per sbattere dentro Un'auto ideale per il pilota fedele al marchio suicida che non sa nulla del web e vuole giurare fedeltà a Microsoft per tutta la vita.
Tutto .NET MVC è davvero, è semplice e ragionevole, e non reinventa il proprio livello da schiaffeggiare sul web. Funziona solo con ciò che è lì per aiutare a mettere fuori qualche piastra per voi. Sono disponibili migliori / meno costosi / free-er framework ma se ti sei già bloccato in .NET, potresti fare molto peggio.
Ma seriamente, tieni @! $ # lontano dalle webform. È quasi morto adesso. Lasciarlo andare. Dì ai tuoi clienti che lo farai per tre volte i soldi se ti promettono anche un contratto di supporto in base all'ora esclusivo e lucrativo per quando vogliono effettivamente fare qualcosa di nuovo o diverso o quando la cazzata inizia a rompersi perché nemmeno MS potrebbe essere infastidito per continuare ad aggiungere a quel colosso di un file ajax.js di 10.000 righe che estraggono dal loro culo DLL dove non puoi toccarlo.
Una soluzione ASP.NET MVC non deve essere più complicata di una soluzione WebForms. Personalmente, trovo che ASP.NET MVC sia in realtà molto più semplice di WebForms, e sicuramente sembra essere intrinsecamente più pulito.
Dalla mia esperienza, molti framework MVC (ASP.NET, Rails, CodeIgniter, ecc.) hanno molte delle stesse funzionalità e convenzioni di base. WebForms è davvero l'anatra strana da una prospettiva web. La mia ipotesi è che la maggior parte dei programmatori web sarebbe molto più veloce nel prelevare ASP.NET MVC rispetto ai WebForm.
Il motivo principale per cui si utilizza ASP.NET MVC su Web Form di ASP.NET è la testabilità. Certo, si può fare una specie di WebForm di test unitari, ma ciò richiede strutture di simulazione e molto dolore. La seconda ragione è che MVC lo rende un po ' più semplice per separare le preoccupazioni. Questo può fornire una grande quantità di riutilizzo del codice e rendere il tuo codice liberamente accoppiato. Ciò non significa che sia impossibile fare lo stesso in ASP.NET con pattern come MVP.
Il lato negativo di MVC è che si perde molta della funzionalità e che è stato incorporato in WebForm nell'ultimo decennio (o quasi). MVC ha fatto molta strada sin dal suo inizio per fornire funzionalità simili.
Per quanto riguarda le prestazioni, qualcuno ha la prova in un modo o nell'altro di quale tecnologia è "più veloce"?
Non penso che uno sia migliore dell'altro. Mi piace molto il framework MVC e l'ho usato con grande successo, ma mi assicuro sempre di scegliere la tecnologia che corrisponde al progetto.
Leggi altre domande sui tag architecture asp.net mvc