Perché dovresti usare MVC su Web Forms?


11

Di recente un architetto ha descritto la nostra azienda come offerta di una soluzione Rolls-Royce (MVC) quando tutto ciò di cui aveva bisogno era una Toyota (Web Form).

Sono curioso di scoprire cosa ne pensi dei moduli web vs MVC come scelta architettonica.


11
Penso che l'architetto non abbia un'ottima conoscenza di ASP.NET MVC.
Adam Crossland,

3
@Chris Webforms non è un sottoinsieme di MVC. Entrambi funzionano completamente indipendentemente l'uno dall'altro. Anche i webform sono vecchi e probabilmente non vengono mantenuti molto più a lungo. Inoltre, per gli sviluppatori Web / UI front-end è l'anticristo.
Erik Reppen,

Risposte:


20

L'analogia Rolls-Royce / Toyota è terribilmente imperfetta e fuorviante. Uno (ASP.NET MVC) non è semplicemente una versione più elaborata o più costosa dell'altro (ASP.NET WebForms). Sono approcci molto diversi per la creazione di applicazioni Web utilizzando ASP.NET.

Per me, la più grande differenza architettonica tra MVC e WebForms è il modo in cui lavorano con l'ambiente senza stato del web: WebForms lavora duramente per costruire una serie di astrazioni che nascondono la natura apolide della programmazione web, mentre MVC abbraccia l'ambiente senza stato e funziona con esso.

Ogni approccio ha i suoi vantaggi e svantaggi, ma mi piace molto come la creazione di siti Web con MVC sia molto più naturale di WebForms (con il suo strato su strato di astrazioni che perdono ).


1
quelle astrazioni volgari sono molto problematiche. Apprendimento Asp .Net MVC ti apre gli occhi sul protocollo http
Michal Franc,

10

Vecchia domanda, ma merita una risposta più dettagliata nel caso in cui qualcun altro abbia ancora un dilemma.

In definitiva, i webform sono una soluzione thin client con la quale si intende che premi un mucchio di graziosi pulsanti e la roba del front-end (client) è costruita per te. Se hai persone che sanno come risolverlo nei moduli web e non ci sono assolutamente problemi di manutenibilità / modificabilità e il sito è completamente a breve termine e disponibile, non c'è nulla di sbagliato in questo approccio. È possibile imparare a fare le tue cose, ma in questo caso richiederebbe che entrambi i moduli web provino a proteggere gli sviluppatori di applicazioni .NET e tutte le cose che fanno sì che la maggior parte degli sviluppatori web sul lato client voglia uccidere Microsoft ingegneri responsabili.

Nel 99,5% di tutti gli altri scenari di casi d'uso, abbiamo smesso di cercare di nascondere il web agli sviluppatori di app perché in realtà, se vuoi scrivere app Web, stai molto meglio imparando davvero come funziona il web. L'ironia delle soluzioni thin vs thin client è che inevitabilmente l'approccio thin client porta inevitabilmente a far schifo il front-end ed è tutt'altro che performante. Ancora più importante, queste soluzioni hanno sempre reso le cose non flessibili come l'inferno per le persone che sanno davvero cosa stanno facendo e non vogliono essere vincolate dal framework in effetti.

Non c'è nulla di così inutile 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 ...

  • Elimina tutti i tag di script "non necessari" nei tag head per impedirti di rovinare le dipendenze degli script. (meglio lasciare che un "sceneggiatore" lo gestisca per te) Concesso, nessuno li mette li 'al giorno d'oggi se sanno cosa stanno facendo, ma è solo un casino.

  • Insiste per racchiudere tutto l'HTML in un tag form enorme. L'HTML non consente i moduli all'interno dei moduli, quindi si fa in modo che i moduli web non siano affatto.

  • Crea come un "ciclo di vita" in 18 passaggi per ciò che dovrebbe davvero ridursi alla reazione agli eventi dell'interfaccia utente interagendo con il browser per inviare messaggi al server e quindi reagire quando il server risponde. Astrarre quel processo con un grande mucchio di immondizia non ha mai avuto luogo (e per essere onesti, la SM 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 uno sviluppatore lato client più giovane ho trascorso un'intera giornata a trovare un modo per fare in modo che un pulsante di invio nella parte superiore della pagina attivasse un pulsante di invio nella parte inferiore di una pagina (presumo a causa di quello cosa dalla forma gigante). Normalmente ciò richiederebbe 5 minuti ma dopo parecchie ore dopo l'ingegnerizzazione responsabile dei JavaScript dei moduli web, ho scoperto che stavano tra l'altro impostando una proprietà che non sapevo nemmeno al momento che ti dice quale sia l'ultimo elemento del modulo da avere il focus era che quando si faceva clic su un pulsante di invio, solo il pulsante di invio ufficiale di Microsoft (tm) funzionava per l'attivazione di un gestore ufficiale di invio di Microsoft (tm).

Quindi no, Rolls-Royce vs Toyota, è completamente irragionevole. Direi di più, una Hyundai perfettamente ragionevole per la quale paghi troppo per un Pinto progettato da Microsoft con un sistema di bordo che fa automaticamente brusche virate di 90 gradi quando scopre che hai acquistato gas o petrolio da qualcuno diverso da Microsoft e viene rilevato un comodo muro in cui sbattere. Un'auto ideale per il guidatore fedele al marchio suicida che non sa nulla del web e vuole giurare fedeltà a vita a Microsoft.

Tutto il MVC .NET è davvero, è semplice e ragionevole, e non reinventa il proprio livello per schiaffeggiare sul web. Funziona solo con ciò che è lì per aiutarti a buttare giù un po 'di piastra per te. Sono disponibili framework migliori / più economici / free-er, ma se ti sei già bloccato nella cosa .NET, potresti fare molto peggio.

Ma seriamente, stai alla larga! @ # $ Dai moduli web. Adesso è quasi morto. Lasciarlo andare. Di 'ai tuoi clienti che lo farai per tre volte i soldi se ti promettono anche un contratto di supporto oraria esclusivo e redditizio per quando vogliono davvero fare qualcosa di nuovo o diverso o quando la merda inizia a rompersi perché nemmeno MS potrebbe preoccupati di continuare ad aggiungere a quel colosso di un file ajax.js da 10.000 righe che estraggono dal loro culo DLL dove non puoi toccarlo.


Ciao Erik, ti ​​ho adorato per la risposta, quindi hai ottenuto il mio entusiasmo. Sto solo imparando HTML 5 e CSS, quindi il tuo post è stato molto istruttivo.
Ciad

+1 Risposta molto bella! Evito MVC da anni perché pensavo che sarebbe stato solo un approccio più complicato ai moduli web. Sembra che in realtà renderebbe più facile quello che cerco di fare con i moduli web (ad esempio cerco sempre di evitare tutti i Microsoft BS come Script Manager).
Ha disegnato Chapin il

6

Una soluzione ASP.NET MVC non deve essere più complicata di una soluzione WebForms. Personalmente, trovo ASP.NET MVC in realtà molto più semplice di WebForms e sembra decisamente intrinsecamente più pulito.

Dalla mia esperienza, molti framework MVC (ASP.NET, Rails, CodeIgniter, ecc.) Hanno la stessa funzionalità e convenzioni di base. WebForms è davvero l'anatra dispari dal punto di vista del web. La mia ipotesi è che la maggior parte dei programmatori web sarebbe molto più veloce nel raccogliere ASP.NET MVC rispetto a WebForms.


5

Il motivo principale per cui dovresti utilizzare ASP.NET MVC su ASP.NET WebForms è la testabilità. Sicuramente puoi provare i WebForms di unit test ma questo richiede framework beffardi e molto dolore. Il secondo motivo è che MVC rende un po ' più facile separare le preoccupazioni. Questo può fornire una grande quantità di riutilizzo del codice e rendere il codice liberamente accoppiato. Ciò non significa che sia impossibile fare lo stesso in ASP.NET con modelli come MVP.

Il rovescio della medaglia di MVC è che perdi molte funzionalità e che è stato integrato in WebForms nell'ultimo decennio (quasi). MVC ha fatto molta strada 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 adatta al progetto.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.