Quando preferire ASP.NET WebForm rispetto a MVC

Webforms vs. MVC sembra essere un argomento caldo in questo momento. Tutti quelli che conosco pubblicizzano MVC per essere la prossima grande cosa. Dalle mie piccole esperienze, sembra ok, ma no, non credo che sarà la fine dei webforms.

Il mio ragionamento, e il ragionamento sul motivo per cui i webform dovrebbero essere scelti su MVC, ha ha più a che fare con una prospettiva aziendale piuttosto che con ciò che è migliore dellaltro.

Tempo / denaro sono i motivi principali per cui i moduli web dovrebbero essere scelti rispetto a MVC.

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

Se hai un grande sito web scritto tutto in moduli web, potresti essere più propenso a creare nuove pagine in moduli web in modo da non farlo ” Non ho due tipi di pagine molto diversi nel tuo sito.

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

La mia azienda ha recentemente eseguito tre pagine di test con MVC. Ci siamo seduti e le abbiamo progettate. Un problema che abbiamo riscontrato è che la maggior parte dei nostri schermi ha la funzionalità Visualizza e Modifica sulla stessa pagina. Abbiamo finito per aver bisogno di più di un modulo sulla pagina. Nessun problema, tranne che non avremmo usato la nostra pagina master. Abbiamo dovuto rinnovarlo in modo che sia le pagine dei moduli web che le pagine MVC potessero utilizzare la stessa pagina master per un aspetto e un aspetto comuni. 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.

Sentivo che cerano troppi file per 3 pagine, ma questo è il mio opinione personale.

Secondo me, sceglieresti webforms piuttosto che MVC se non hai il tempo / denaro da investire nellaggiornamento del tuo sito per utilizzare MVC. Se adotti un approccio mezzo arsato a questo, non sarà migliore dei moduli web che hai ora. Peggio ancora, potresti persino impostare questa tecnologia per il fallimento nella tua azienda se è incasinata, poiché i vertici aziendali potrebbero vederla come qualcosa di inferiore a ciò che sanno.

Commenti

• Questa è una buona risposta. Ti ho dato +1 perché le tue esperienze personali sono apprezzate. Ma questo è un fallimento a causa della mancanza di esperienza / abilità degli sviluppatori che ho chiesto di evitare . Non sono convinto che Microsoft sceglierebbe di non contrassegnare una tecnologia come obsoleta semplicemente per paura della curva di apprendimento per MVC. Potrebbe essere il caso, ma ‘ non sono ancora convinto.
• @ P.Brian.Mackey – Non ‘ ho detto che lo sviluppo di moduli è più veloce di MVC. Hai chiesto di escludere questo argomento. Discutere tempo e denaro per formare il proprio personale è un argomento diverso. MS non ha ‘ contrassegnare i moduli web come obsoleti per un motivo importante: i clienti aziendali hanno trascorso anni a sviluppare client web in moduli web e hanno vinto ‘ non vedo bene di dover investire tempo e denaro per laggiornamento.
• @Raynos – Se tutti i membri del team erano competenti in MVC e la tua azienda stava avviando un nuovo progetto, lunico motivo per cui potrei vedere qualcuno che sceglie i moduli web è la scelta personale.
• Conosco intimamente entrambe le tecnologie. Tutti i miei progetti web sono realizzati con mvc e lavoro in unazienda dove ho la libertà di fare qualunque sia lapproccio migliore. Scelgo sempre MVC.
• Ho iniziato con Webforms e una volta scoperto MVC sono passato a quello. Non ‘ non so come qualcuno possa difendere i moduli web. Ciclo di vita della pagina e un modulo per lintera pagina? Ma stai scherzando? Yahoo sitebuilder era probabilmente il cliente designato per questo, ma anche loro non ‘ volevano quella spazzatura.

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 delloutput per vedere cosa sta generando ASP .Net.
• ViewModels ti offre un potere immenso ed evita la necessità di eseguire il binding di controllo manuale ed elimina molti errori relativi al binding.
• Puoi avere più moduli su una pagina. Questa era una grave limitazione dei WebForm.
• Il Web è senza stato e MVC corrisponde più da vicino allarchitettura del Web. Webforms introduce lo stato e i bug hai con esso introducendo ViewState. ViewState è automatico e funziona in background, quindi non si comporta sempre nel modo desiderato.
• Le applicazioni Web devono funzionare con ajax in questi giorni. Non è più accettabile caricare lintera pagina. MVC rende ajax molto migliore, più facile ed efficiente con JQuery.
• Perché puoi avere più moduli su una pagina e perché larchitettura è guidato dalle chiamate agli URL, puoi fare cose strane come ajax caricare un modulo diverso, come un modulo di modifica nella tua pagina corrente utilizzando JQuery. Una volta capito cosa ti consente di fare, puoi fare cose incredibili facilmente.
• ASP .Net WebForms non è solo unastrazione su html, è estremamente complessa. A volte potresti ottenere 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 alternative.
• WebForms non è una buona tecnologia per i progettisti. Ai progettisti spesso piace lavorare direttamente con html. In MVC è “una vista, in WebForms è mezza giornata di lavoro.
• Poiché la piattaforma web si evolve velocemente, WebForms non terrà il passo. consapevole di nuovi tag o funzionalità di HTML5, eseguirà comunque il rendering degli stessi elementi a meno che non si ottengano (spesso) costosi controlli di terze parti o si attenda che Microsoft emetta 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 levoluzione di WebForms, ma questa era 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.

Commenti

• +1 per sottolineando più forme. Inoltre, il fatto che i moduli Web HTML generati è il più delle volte non molto SEO friendly (come in: grandi blocchi di viewstate in cima alla pagina)
• Devo essere daccordo al 100% con questa risposta. Alla fine della giornata, WebForms fa le cose sul lato client (html / browser) molto più difficile. Devi letteralmente combattere il framework per ottenere qualcosa. Una pagina aspx finisce con molto più codice a causa dei controlli del server rispetto a una pagina cshtml in genere. @ šljaker Se inizi a disattivare ViewState ed eviti i controlli del server, ‘ hai abbandonato gran parte dei WebForm a quel punto. Non ‘ questo argomento è particolarmente convincente.
• Puoi avere semplici controlli html in WebForms, nessuno ti obbliga a usare i controlli Server. Puoi avere un modulo Web completo senza stato, nessuno ti obbliga a usare ViewState. Puoi usare ajax e jQuery completi in Webforms, nessuno ti impedisce di usare jQuery. Puoi implementare il routing dellURL, nessuno ti obbliga a utilizzare lURL di base del file statico. Disegnare manualmente una pagina con CSS consuma il tempo necessario per MVC. Puoi progettare la pagina HTML direttamente su Webform.
• @mjb: se ‘ t usi i controlli server, ViewState e così via, perché usare WebForms quando MVC è più vicino a ciò che ‘ stai facendo? ‘ è come guidare un trattore per lavorare ma non fare fuoristrada o usare la pala / zappa o le barre stabilizzatrici. A quel punto perché non usare semplicemente unauto?
• @Tjaart Non è del tutto corretto che non puoi avere più moduli sulla pagina ASPNET.Potresti avere tutti i moduli che desideri nella pagina ASPNET, ma potresti avere un solo modulo server: modulo con runat = ” server ” attributo.

Ho inviato unemail a Scott Guthrie , un esperto MVC di Microsoft. E probabilmente luomo più qualificato per rispondere a questa domanda. È stato così gentile da rispondere:

“Clienti diversi cercano approcci di programmazione diversi e molti amano WebForms e pensano che sia fantastico. Altri amano MVC e penso che sia fantastico. Ecco perché stiamo investendo in entrambi. “

Quindi, per me questo dice che non è un problema tecnico. È più un “problema morbido”, se vuoi. Uno di preferenza personale. Questo è in linea con quanto hanno detto molti di voi.

Grazie per tutte le risposte.

Commenti

• Scott Guthrie ha inventato il framework MVC per ASP.NET durante un volo di ritorno da Londra a Seattle nel 2006/7. Adesso che ci penso, ha praticamente inventato anche .NET ( en.wikipedia.org/wiki/Scott_Guthrie ). Definirlo un ” esperto ” è un enorme eufemismo 😉
• Questo ‘ una bella risposta politica di Scott Guthrie. Se lui stesso stesse investendo la propria applicazione Web, ‘ vedresti un progetto MVC e per qualsiasi cosa che ‘ non possa essere eseguita in MVC, Silverlight sarebbe il fallback. Non ‘ prendere questo come un commento negativo nei confronti di WebForms, penso che i WebForms siano ottimi per applicazioni interne di dimensioni ridotte che possono trarre vantaggio da componenti di terze parti come quelli creati da Telerik. ‘ sono contento che Microsoft stia andando avanti con entrambe le tecnologie.
• ” Scott Guthrie ha inventato il framework MVC per ASP .NET durante un volo ” Penso che banalizzi davvero MVC. Non ‘ non conosco Scott Guthrie, ma ‘ sono disposto a scommettere che stava valutando come MVC potrebbe essere implementato in ASP.NET per un po e ha utilizzato quel lungo volo per implementare un prototipo essenziale come prova del concetto.
• ” Ecco perché stiamo investendo in entrambi. ” E quando vediamo che i moduli web iniziano a diminuire, lo abbandoneremo senza pietà perché investire in un prodotto definitivamente morto non è nel nostro miglior interesse commerciale.
• Fino a non viene più insegnato nelle scuole, per molti anni sarà sempre applicabile nel mondo degli affari. I college e le scuole superiori continuano a offrire corsi introduttivi e avanzati su vb.net. NON sta andando da nessuna parte !!!

Questa è una domanda obsoleta con molte risposte ma nessuna se avessi la risposta mi sarei aspettato di essere elencato.

La risposta breve è:

• Usa ASP.NET MVC se intendi costruire correttamente unapplicazione web con la programmazione moderna convenzioni e modelli adottati dal settore per la piattaforma ASP.NET. Sul lato negativo ci si aspetta che tu sappia come funzionano HTML e le risorse lato client (Javascript, CSS), oltre a migliorare la mentalità di programmazione MVC che ha una curva di apprendimento ripida ma raggiunge una fine improvvisa una volta afferrata.
• Utilizza i moduli Web ASP.NET se “stai utilizzando o desideri utilizzare una GUI -centric, RAD (Rapid Application Development) , approccio drag-and-drop alla prototipazione di qualcosa molto rapidamente, ad esempio il comportamento del pulsante / griglia di dati cablato entro 15 minuti e la soluzione non è pensata per essere qualcosa di supportato da sviluppatori. Oppure Utilizza ASP.NET Web Forms se hai un background in GUI o nello sviluppo di Windows Form e desideri trasferire il tuo conoscenza del Web.

Ma per esaminarlo correttamente, devi comprendere la storia di ciascuno.

ASP.NET Web Forms era la risposta di Microsoft coloro che hanno creato applicazioni web dinamiche utilizzando Visual Basic 6 Ac controlli tiveX, DLL VB6 sul server e ASP Classic. A quel tempo, lo sviluppo web utilizzando questi strumenti Microsoft era un vero casino. Insieme alla totalità di .NET Framework, che era loutput di Microsoft che essenzialmente tornava al tavolo da disegno su come eseguire una programmazione aziendale produttiva sullo stack di Windows, ASP.NET Web Forms era, ai suoi tempi, sorprendente e bello.

Lintero approccio era quello di fornire 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.Lidea era che, proprio come con un VB6 / WinForms “Form” (una finestra), allo stesso modo una pagina web è un modulo (proprio come una finestra, vedi) , e su quel modulo si potevano trascinare e rilasciare etichette, caselle di testo, griglie di dati, pulsanti e altre cose a cui erano abituati gli sviluppatori di GUI VB / WinForms.

Per fare in modo che un pulsante esegua qualcosa, dopo averlo trascinato basta fare doppio clic su di esso nel designer e boom sei nelleditor del codice, dicendo al modulo cosa fare quando “fai clic su “si verifica levento. Questo era esattamente il modo in cui gli sviluppatori della GUI di Windows creavano il software utilizzando gli strumenti della GUI di VB6 e strumenti concorrenti, tranne che ora il codice è in esecuzione sul server! Wow!

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

Sfortunatamente, questo modello di programmazione enfatizza così tanto la metafora della programmazione GUI di Windows che porta con sé il peso dei suoi necessari dettagli di implementazione , tutto il bagaglio ingombrante nca essenziale per accogliere i cicli di vita dellevento e nascondere i brutti dettagli del semplice HTML e script che questi componenti e controlli drag-and-drop avrebbero prodotto. E alla fine della giornata, gli sviluppatori che supportano applicazioni reali dovevano inevitabilmente scavare in profondità in questi componenti o scriverne di propri, e di conseguenza avrebbero combattuto battaglie con questa infrastruttura, battaglie che lascerebbero dietro di sé pile su pile di cruft, capelli tirati e lacrime.

Indietro. 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 aziendali, database e una piccola manciata di ottimi 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 dellapplicazione e farla finita con le metafore della GUI?

È qui che entra in gioco ASP.NET MVC. È iniziato da una ribellione di sviluppatori che si facevano chiamare “Alt.Net” che volevano tornare ai principi di sviluppo del software corretti e puri. Niente più confusione, concentrati solo sugli obiettivi di business e sulle best practice del software.

Ciò in cui si traduce realmente in questo caso è:

1. Separazione delle preoccupazioni . Ad esempio, un componente dati non ha bisogno di sapere come verranno renderizzati i suoi dati, né il markup della vista deve essere gravato dai 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 test.
2. Esposizione e supporto completo per lesposizione alle parti essenziali di HTML e risorse correlate . In Web Forms, lHTML è nascosto, gli sviluppatori sono scoraggiati dal preoccuparsene. In ASP.NET MVC, gli sviluppatori sono piuttosto incoraggiati a gestire questi dettagli, in effetti è una necessità. Il vantaggio qui è che lo sviluppatore può riapprendere ad apprezzare la semantica pulita di HTML, CSS e script e lavorare con piuttosto che contro di essa.
3. Testabilità degli oggetti aziendali . I controller ei modelli sono molto più adatti per i test di unità programmatici, in modo che le implementazioni possano essere convalidate per soddisfare gli obiettivi di business e le modifiche possano essere verificate in modo che non si interrompano. Con Web Forms era difficile testare poiché i componenti non erano progettati per essere testati individualmente e lintero output di sviluppo ruotava attorno ai moduli di pagina e al loro ciclo di vita degli eventi con il fango 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. Lintera storia sarebbe stata diversa se avessimo a che fare con il linguaggio Assembly e C.

Espandendo il n. 2, quindi, un altro obiettivo di ASP.NET MVC è consentire agli sviluppatori di organizzare i dettagli front-end di la parte “visualizza” delle loro soluzioni e sfrutta le ricche basi che il resto del settore ha costruito sulla piattaforma client front-end.

Scoprirai che gli sviluppatori ASP.NET MVC si sentono a casa utilizzando ricche librerie Javascript e tecniche di creazione di modelli lato client senza combattere con larchitettura lato server. Questo non era originariamente il caso di ASP.NET Web Forms, perché Web Forms non vuole affatto che tu guardi lHTML o lo script, tranne se devi davvero , nel qual caso, attenzione, non è per i deboli di cuore .

Commenti

• Questa è una buona risposta, ma # 1 e # 2 sono sbagliati (WF non richiede un componente per sapere dove i suoi dati proviene da, è unopzione e hai sempre aggiunto HTML ai tuoi file ASPX per supportare i tag asp che stai rendendo. Non hai mai avuto bisogno di scavare in profondità e combattere i controlli a meno che tu non stia cercando di accedere a una funzionalità ASP non destinata agli sviluppatori interazione. I punti importanti sono la testabilità e il design pattern.)

Sono un convertito completo e totale ad ASP.NET MVC e non ho guardato indietro, questo ha detto che devo ancora mantenere diverse app WebForm di grandi dimensioni. Ecco la mia opinione:

WebForms
Usali quando hai una vita seria a che fare con le griglie. I controlli della griglia sono davvero molto utili quando si dispone di un semplice set di dati che si adatta perfettamente a un formato tabulare e si desidera fornire agli utenti un modo semplice per aggiornare i record. Sì, lo so che MVC 4 ha una cosa tipo elenco Ajax davvero accattivante che puoi usare che funziona alla grande ma, nella nostra attività spesso abbiamo bisogno di far funzionare qualcosa ieri e le buone griglie vecchio stile funzionano alla grande e gli utenti sono felici di esserlo in grado di scorrere una griglia con gioia. Per me questa è davvero la cosa migliore di WebForms per me; ma, come Ryan ha sottolineato che WebForms può essere un grande pasticcio perché “stai giocando da entrambe le parti del recinto da un elegante file code-behind. 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
Usalo quando vuoi veramente lanciarne uno tuo e hai lopportunità di avviare unapplicazione da zero. Avere unapplicazione MVC chiaramente definita è un po più faticoso per iniziare, ma i suoi vantaggi in termini di manutenibilità superano il costo di configurazione iniziale. Se vuoi fare interazioni Ajax interessanti, preferisci scrivere il tuo modello con codice, come url e percorsi puliti, ed essere in grado di controllare lintero flusso della tua app, questa è sicuramente la strada da percorrere. Ci vuole un po per abituarsi allinizio, ma penso che sia lopzione migliore per le app greenfield.

In conclusione, per me, si tratta di griglie e! griglie. 🙂

Commenti

• +1 per la bella immagine fornita con ” che riproduce entrambi i lati del fence da un elegante file code-behind “.
• Molto utile questo. ‘ sto utilizzando unapp basata su una griglia molto pesante e ‘ ho escluso silverlight, xbap ed è stato uno spettacolo tra questi due.

La mia esperienza:

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

Dopo in questa esperienza, ho provato a scrivere unaltra app utilizzando webforms e mi sono sentito frustrato dopo aver lottato per circa un giorno con il modo in cui webforms tenta di proteggere lo sviluppatore dalla realtà che “sta sviluppando unapplicazione che utilizza html, javascript e css.

Ho quindi provato MVC e avendo un controllo più diretto sulloutput (e un po di esperienza con il paradigma MVC di CakePHP) sono stato in grado di completare quella semplice app esattamente come volevo in circa 1/2 giornata.

La disponibilità di potenti framework UI come jQuery molto eli minimizza lattrattiva di rinunciare al controllo diretto delloutput a favore dellutilizzo di componenti dellinterfaccia utente preconfigurati spesso ingombranti.

Commenti

• @JimG – Uhh , tutto ciò che coinvolge una persona che inserisce record senza associazioni interessanti in un database e che quella persona o qualcun altro li legga / stampi in un altro punto può essere fondamentalmente impalcato utilizzando un framework MVC. Certo, non è ‘ per la maggior parte delle app, ma ‘ è molto più di quanto puoi fare con Moduli. Immagino che il tuo -1 dimostri il mio punto di vista.
• Questo ‘ è 1/4 di giornata.
• Ma se i requisiti ammontano a ” Ho bisogno di unapp con due ruoli, uno per registrare alcune informazioni, laltro per esaminarle e non ‘ davvero importa come appare. ” Allora sì, ‘ è abbastanza fattibile.
• mi dispiace, ma sviluppare unapp webforms per inserire dati e visualizzare i dati è così semplice che può essere fatto in poche ore. la creazione della struttura di unapp MVC, controller, visualizzazioni e azioni richiederebbe la stessa quantità di tempo, ma non ti porterà a un prodotto finito.
• @Dementic Di solito per una semplice app MVC si costruiscono modelli, quindi si impilano i controller e le visualizzazioni e / o si generano controller / visualizzazioni con scaffolding. Niente che richieda molto tempo.

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 risolverlo durante la notte con i moduli, inoltre, se ho un problema di velocità su una pagina, un ottimo libro su asp.net la velocità è utile (Rick Kiessig è luomo).

webforms è per ex windows people mvc è per web people

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

I miei 2 centesimi sono per utilizzare sempre ASP.NET MVC per nuovi progetti se ne hai la possibilità. Secondo me, i moduli web non sono un buon modo per sviluppare app web, punto.

Penso che astrarre il REST di base sia un male, lintero modello di postback è pessimo, il modo in cui html / css viene consegnato con una dipendenza sulleditor della GUI è pessima, lenfasi su cose come procedure guidate e GUI per impostare le cose è pessima, gli URL sono pessimi.

Commenti

• potresti spiegare in modo più dettagliato perché la pensi così?
• Penso che lastrazione del REST di base sia tornato, lintero modello di postback sia tornato, il modo in cui html / css viene consegnato facendo affidamento sulleditor GUI è negativo , lenfasi su cose come procedure guidate e GUI per impostare le cose è pessima, gli URL sono pessimi, ecc e così via

Non ho ancora visto questa considerazione avanzata tra le 15 risposte esistenti a questo thread, ma penso che sia “è degno di 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à uninterfaccia sullo stesso set di dati di un Win Forms esistente (o sviluppato contemporaneamente) o Progetto WPF. Ciò consente agli sviluppatori di passare più facilmente da un progetto allaltro, poiché la logica dellapplicazione può essere abbastanza simile tra i due.

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

Commenti

• + 1 Certamente un argomento ragionevole per Webforms. La mia paura è che i team seguano questa mentalità per evitare di imparare cose nuove. MVC è pieno di molti schemi che potrebbero non essere familiari a una squadra. Lapprendimento di questi tipi di modelli e la loro implementazione porta a una migliore aderenza ai principi SOLID che si traduce in una migliore manutenibilità complessiva. Queste tecniche collaudate sono anche la vera chiave per la riutilizzabilità.

La nostra ragione per non andare a MVC alcuni anni fa 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 desideriamo utilizzare nella versione 4 richiedono un server Windows 2012 (con i socket Web tramite IIS8). Immagino che tra un anno in più accetteremo di più MVC poiché si spera che saranno disponibili più controlli di terze parti, la tecnologia si sarà stabilizzata e avremo linfrastruttura per supportarla.

Commenti

• Ti dispiacerebbe elencare alcune di queste funzionalità che secondo te richiedono Windows Server 2012?

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

Il tempo per la formazione apprendimento MVC o il tempo per ottenere una consegna. Tutte queste cose sono importanti per scegliere luno o laltro approccio.

Non è che uno sia migliore di un altro, semplicemente sia lapproccio che i framework hanno pro e contro.

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

Saluti,

Lunico motivo per cui sceglierei WebForms invece di MVC è perché hai molti più controlli UI di terze parti per WebForms rispetto a MVC. Scelgo MVC perché ho lavorato troppo con WebForms e voglio lavorare con qualcosa di fresco / nuovo, ma ancora da MS Shop 🙂

Fondamentalmente, nulla ti impedisce di disattivare il viewstate in WebForms e utilizzare ViewModels e cicli if / for invece dellassociazione di modelli e dei controlli lato server.

È questo codice WebForms o MVC:

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

Lunica limitazione che ho trovato in WebForms è che se utilizzi Dependency Injection / Inversion of Controllo, non puoi avere liniezione del costruttore poiché le pagine WebForms devono avere un costruttore senza parametri, quindi devi usare liniezione di proprietà. È davvero un grosso problema?

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

ASP.NET Webforms ti offre un grande controllo sul client dal lato server, con accesso diretto praticamente tutto. Essenzialmente la vista e il controller sono la stessa cosa, il che ti dà molta potenza e la maggior parte delle volte un sacco di confusione.

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

Essenzialmente, la differenza sta nel fatto che molto più (in genere tutta) lelaborazione per visualizzare i dati al file di visualizzazione e lasciando la logica aziendale e il resto nel controller, mantenendoli entrambi più puliti per convenzione, ma anche con un accesso minore luno allaltro rispetto a quanto consentito dai moduli web.

Commenti

• Quindi QUANDO dovrebbero essere preferiti i webform rispetto a MVC? Questo non risponde alla domanda originale dei poster.
• @WeekendWarrior – Lo fa, quando vuoi più accesso lato server al client, scegli webforms. Se desideri un maggiore disaccoppiamento del client / server nel tuo codice, scegli MVC. Alla fine della giornata, entrambi fanno la stessa identica cosa. I filtri di reindirizzamento fanno la stessa cosa degli URL MVC e puoi spostare il codice webforms dietro a un livello intermedio separato per disaccoppiarlo di più. weblogs.asp.net/scottgu/archive/2010/01/24/…
• Per quanto riguarda il tuo terzo punto, quella logica aziendale finisce nel file .aspx.cs – penso che sia colpa degli sviluppatori. ‘ non / si suppone / sia presente. In moduli web, .aspx è la ” vista “, .aspx.cs è ” controller ” equivalente, destinato a elaborare il codice che si riferisce direttamente solo allinterfaccia utente eseguendo il polling di un livello aziendale o di un livello di facciata aziendale a grana grossa. Il fatto che le persone inseriscano la logica aziendale nel file .aspx.cs è solo una cattiva programmazione. Potrebbero anche mettere la logica aziendale nella vista in MVC! MVC non ‘ t forza la separazione di queste cose.
• Essenzialmente ha più ragione delle altre risposte pubblicate qui. ASP.net è lidea di base alla base di una famiglia di tecnologia web modulare creata da Microsoft. Il modulo ASP.net MVC potrebbe essere un clamore temporaneo ma di sicuro non è lultimo, tutto inizia con ASP.net, quindi quando scegliere ASP.net, se non pensi che MVC non faccia per te, forse sei più interessato a qualcosa altrimenti OWIN o …, qualcosa di più avanzato, o creato il tuo framework per le tue attività. Potresti anche non aver bisogno di ASP.MVC e saltarlo e andare su Owin o Katana, ma finché non sei lì usa asp.net

Secondo me, sono abbastanza correlati e hanno più o meno le stesse capacità che dovrebbero fino alle preferenze.

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

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

Si tratta di una scelta personale, supponendo che siamo tutti competenti con la tecnologia che utilizziamo. Uso lapproccio di progettazione WebForms da molti anni e devo dire che lunico svantaggio è che a causa del suo approccio semplicistico, molte persone non si prendono il tempo per scoprire le sue vaste capacità.

Di recente ho utilizzato MVC per completare un progetto e, sebbene lapproccio progettuale allo sviluppo di applicazioni mi piaccia abbastanza (che ti dà più controllo, URL puliti, SOC, ecc.), non cè davvero molto che fornisce , che WebForms non può “t. In effetti, lemergere di jQuery e il suo funzionamento con WebForms (così come MVC) ha reso questi argomenti meno problematici. E quando le persone parlano della separazione delle preoccupazioni come vantaggio che MVC ha rispetto a MVP, chiedo loro quanto conoscono la programmazione orientata agli oggetti e quanto mettono in pratica il principio di astrazione e polimorfismo.

Al momento sono a mio agio nelluso di entrambe le tecnologie e scelgo e scelgo in base alla situazione. Francamente, è su a te, ma resta la verità che non tutti si prendono il loro tempo per apprendere in profondità di cosa è capace una particolare tecnologia.

Commenti

• Idem su le vaste capacità dei moduli web. La maggior parte delle persone vede le ruote di formazione dei moduli web e lo confronta con MVC.
• Non ha molto senso imparare unastrazione oltre a HTML e Javascript oggigiorno (anche in 2013). ‘ non ti gioverà alle opportunità future. HTML e Javas cript va benissimo così comè. Combatterla è una battaglia persa.

Quando mi trovo di fronte a un problema di programmazione, guardo spesso al Web per le risposte. Webforms ha tonnellate di informazioni / componenti su come fare qualsiasi cosa. In MVC, a causa del minor numero di fonti online e degli strati di astrazioni necessari per far funzionare qualcosa, ha posto un limite alle cose che avrei potuto fare una volta. Il totale MVC uccide la mia produttività come sviluppatore mentre con Webforms non è così. Quindi per ora mi limito a webforms finché MVC non è sufficientemente maturo da sostituirlo.

Bene, WebForms ha più risorse di apprendimento disponibili (semplicemente perché è più vecchio) e quindi è più probabile che i nuovi programmatori che non sono al corrente “trovino informazioni relative a questa vecchia tecnologia in contrapposizione a cose più recenti come MVC.

I programmatori senior / esperti sono più vecchi e saranno più abili nella tecnologia più vecchia perché ci hanno programmato più a lungo di quanto hanno fatto hanno in quello più recente.

A meno che tu non possa spendere i soldi e gli sforzi per far sì che i tuoi ragazzi siano competenti in MVC come sono nelle applicazioni WebForms, proverai senza dubbio a trattenere laggiornamento al nuovo piattaforma il più a lungo possibile.

Quindi presenta diversi problemi logistici: i vantaggi di MVC superano il costo in termini di minore qualità e tempo di distribuzione? Se ho un sito scritto interamente in WebForms, varrebbe lo sforzo e il denaro per integrarvi MVC?

Come affermato da un commentatore precedente, MVC ti impedisce anche di raggiungere lo stesso livello di interfaccia con il controller come potresti fare con WebForms. Sebbene io sia favorevole al lato “Impedisci allutente di riempire / apprendere”, può comunque essere irragionevolmente problematico per i team distribuire / implementare un programma che aderisca fanaticamente a quel paradigma per tutto ciò che scrivono.

Penso che il divario tra queste due tecnologie non sia così ampio come un tempo.

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

Per rispondere direttamente alla tua domanda penso che dipenda dalle preferenze e / o qual è il progetto. Entrambi adottano un approccio allo sviluppo significativamente diverso. Personalmente ho lavorato per passare a MVC, ma mi diverto ancora a lavorare con Webforms. Penso che la risposta a se dovresti usare MVC o Webforms è che tu decida sperimentando entrambe le tecnologie.

Commenti

• Webforms e MVC raccomandano un atteggiamento di sviluppo web radicalmente diverso per impostazione predefinita, questo è importante , pochi sviluppatori deviano da ” il valore predefinito “. Entrambi possono essere utilizzati per ottenere lo stesso risultato.