2009-06-23 18 views
28

Ho avuto una discussione con uno dei miei amici, che è un architetto in una grande azienda di internet. Fondamentalmente stava dicendo che ASP.NET MVC non è per le applicazioni aziendali su larga scala, che non è flessibile come WebForm e che un'app MVC sarà più lenta di un'app di moduli Web.ASP.NET MVC vs WebForms: confronto velocità e architettura

Dalla mia esperienza di lavoro con MVC, posso dire che è più flessibile ed è più leggero perché non c'è il ciclo di vita della pagina, lo stato di visualizzazione, ecc. Dovrebbe quindi caricarsi più velocemente. Per quanto ne so, MVC è progettato per il traffico di medie e grandi dimensioni.

Cosa ne pensate? Qualcuno ha paragonato velocità e prestazioni? E ASP.NET MVC è migliore per le applicazioni su larga scala rispetto ai WebForm di ASP.NET?

In breve, tra queste due scelte, quale sceglieresti di utilizzare per un'applicazione enterprise su larga scala?

+3

Penso che vogliate rivedere l'ultima frase, poiché sia ​​MVC che WebForm sono ASP.NET. –

+0

fatto grazie per l'heads up – Sergey

+0

ancora di più: intendevi "è ASP.NET MVC migliore ... di ASP.NET WebForms " –

risposta

29
  • velocità di sviluppo: WebForms
  • Prestazioni Velocità: MVC
  • Facilità d'uso: WebForms (tipicamente) Testing
  • Unità: MVC (in genere)
+15

La facilità d'uso è soggettiva. Ho visto persone che pensano le forme web sono facili e quelle che pensano MVC è più facile Velocità di sviluppo Penso che si stabilizzerà nel tempo in quanto asp.net MVC diventa più maturo e supportato – dtc

+1

Lì, qualificato: P –

+7

È possibile testare le applicazioni di moduli Web con la stessa semplicità come applicazioni MVC se sono state create correttamente, con un'adeguata separazione delle preoccupazioni.Non abbiamo avuto bisogno dell'introduzione di MVC per insegnarci come farlo.E 'solo che molti test di unità ignorati, periodo –

4

Penso che MVC sia un framework più leggero e più performante perché non fa un sacco di cose che il framework WebForms fa subito, come ad esempio il viewstate. Non penso che sarebbe corretto dire che MVC non è per applicazioni su larga scala, poiché probabilmente si adatta meglio di WebForm in termini di prestazioni. In termini di funzionalità out-of-the-box, WebForms fa di più per te perché gestisce lo stato tra i post per te, tramite viewstate, ecc.

Non ho alcun collegamento al confronto delle prestazioni con me, ma sarei estremamente sorpreso se non ce ne sono là fuori. Anche Microsoft probabilmente ne ha alcuni.

7

Questo sito è un esempio migliore delle prestazioni e del ridimensionamento di ASP.net MVC

Alcune funzionalità che ritengo necessarie per Enterprise e che MVC fornisce sono

  1. Unit testing - anche se ci vuole tempo per implementare questo inizialmente fa risparmiare un sacco di tempo in futuro

  2. separazione degli interessi - questo migliora notevolmente lo sviluppo e la modifica della velocità

  3. Prestazioni - poiché sia ​​MVC che Webform utilizzano lo stesso ASP.net del framework principale e MVC è più leggero e conforme a HTTP che offre la possibilità di scommettere ter performance

+3

Tutti e tre di questi possono essere ottenuti utilizzando WebForms. –

+1

Mi piacerebbe davvero sapere come fare tutto ciò in WebForms ... – Liao

+0

@liao - per i primi due punti, stare lontano dal mettere tutto in codice dietro sarebbe la mia ipotesi. – user20358

1

La programmazione groupthink e cargocult è forte in questa discussione. Il tuo amico architetto ha entrambi ragione (probabilmente per le ragioni sbagliate) e allo stesso tempo sbagliato.

che non è flessibile come WebForms

Questo è solo stupido.Puoi fare qualsiasi cosa con qualsiasi cosa. Sono entrambi incredibilmente flessibili. In termini di flessibilità, MVC è probabilmente il vincitore chiaro in quanto è possibile ottenere facilmente la programmazione orientata agli aspetti (AOP) utilizzando ActionFilters. Un altro motivo per cui MVC è probabilmente il vincitore qui è che l'iniezione di dipendenza è pensata in MVC. È possibile avere l'inversione dell'iniezione di controllo e dipendenza in WebForms ma richiede implementazioni complesse che coinvolgono il modello Model-View-Presenter.

L'app MVC sarà più lenta di un'app di moduli Web.

Questo non è valido per la richiesta, come scritto. Qualsiasi applicazione può essere scritta più lentamente in quanto è un processo complesso che coinvolge molti aspetti per raggiungere un prodotto finale. Tuttavia, in termini di velocità raw. Le forme Web sono notevolmente più veloci. https://stackoverflow.com/a/20253243/37055

che è più leggero perché non c'è ciclo di vita pagina, ViewState, ecc .. E 'dovrebbe quindi caricare più velocemente per lo meno

Questo è anche un'istruzione non valida per fare. Il ciclo di vita della pagina è irrilevante in tutti gli aspetti perché ci sono cicli di vita del corollario in MVC rispetto a controller e filtri di azione. Lo stato di visualizzazione è interessante ... se si sceglie di riempire 100 e 1000 di kilobyte di dati nello stato di visualizzazione che richiede che ogni postback sul server abbia una richiesta da 1MB-5MB, sì sarà ovviamente più veloce fare quasi tutto diversamente. Questo non è un errore di webform, tuttavia Webforms ti permette di cadere molto facilmente nella fase di fallimento con viewstate.

ASP.NET MVC è migliore per le applicazioni su larga scala rispetto ai WebForm ASP.NET?

No. Tuttavia la risposta a questa domanda "è ASP.NET WebForm per app su larga scala rispetto ai WebForms ASP.NET?" La risposta è anche No. La risposta è no, perché la risposta è sempre dipende da. Ogni framework ha pro/contro e devi misurarli, non ci sono risposte definitive.

Se stai costruendo un sito basato sui contenuti, chi ha il compito è quello di avere i tempi di caricamento delle pagine più veloci possibili, come ad esempio www.microsoft.com, quindi potresti davvero scegliere le webform.

quale sceglieresti di utilizzare per un'applicazione enterprise su larga scala?

In primo luogo, molto probabilmente non si ha questo problema. Non si sarebbe in grado di fare questa domanda se si fosse veramente responsabili di progettare un'applicazione enterprise su larga scala. (o il processo di assunzione in realtà non richiedeva esperienza di sviluppo su larga scala).

In termini di un'applicazione su larga scala, la struttura scelta è quasi priva di significato. Le applicazioni su larga scala sono basate sulla messa in coda. Sfrutteranno strumenti come MSMQ direttamente o tramite un servicebus come: Mass Transit, Azure Service Bus o NServiceBus. Solo con l'accodamento puoi raggiungere la scala per gestire milioni di richieste come fanno Amazon, Ebay e ogni altro giocatore importante.