När ska jag gynna ASP.NET WebForms över MVC

Webblanketter mot MVC verkar vara ett hett ämne just nu. Alla jag känner visar MVC att vara nästa fantastiska sak. Från mina små dabblings i det verkar det ok, men nej jag tror inte att det kommer att vara slutet på webbformulär.

Mitt resonemang och resonemanget för varför webbformulär skulle väljas framför MVC har mer att göra med ett affärsperspektiv snarare än vad det ena är bättre än det andra.

Tid / pengar är de största anledningarna till att webbformulär skulle väljas framför MVC.

Om de flesta av dina teamet känner till webbformulär, och du har inte tid att få dem snabbare på MVC, koden som kommer att produceras kanske inte är av kvalitet. Att lära sig grunderna i MVC och sedan hoppa in och göra den komplexa sidan som du behöver göra är väldigt olika saker. Inlärningskurvan är hög så du måste ta hänsyn till detta i din budget.

Om du har en stor webbplats skriven i webbformulär kan du vara mer benägen att skapa nya sidor i webbformulär så att du inte ” Jag har inte två väldigt olika sidor på din webbplats.

Jag säger inte att det är en helt eller inget attityd här, men det gör din kod svårare att upprätthålla om det finns en uppdelning av båda , särskilt om inte alla i teamet är bekanta med MVC.

Mitt företag gjorde nyligen tre testsidor med MVC. Vi satte oss ner och designade dem. En fråga som vi stötte på är att de flesta av våra skärmar har Visa och redigera funktionerna på samma sida. Vi slutade behöva mer än ett formulär på sidan. Ingen biggy, förutom då skulle vi inte använda vår huvudsida. Vi var tvungna att modernisera det så att både webbformulärssidorna och MVC-sidorna kunde använda samma mastersida för att se ut och känna. Nu har vi ett extra lager häckande.

Vi behövde skapa en helt ny mappstruktur för dessa sidor så att den följde rätt MVC-separation.

Jag kände att det fanns för många filer för 3 sidor, men det är min personlig åsikt.

Enligt min mening skulle du välja webbformulär framför MVC om du inte har tid / pengar att investera i att uppdatera din webbplats för att använda MVC. Om du gör en halv arsed tillvägagångssätt för detta, det blir inte bättre än de webbformulär du har nu. Ännu värre, du kan till och med ställa in den här tekniken för att misslyckas i ditt företag om den är trassig, eftersom den översta ledningen kanske ser det som något sämre än vad de vet.

Kommentarer

• Detta är ett bra svar. Jag gav dig +1 eftersom dina personliga upplevelser är uppskattade. Men detta är misslyckande på grund av brist på erfarenhet / kompetens hos utvecklarna som jag bad att undvika Jag är inte övertygad om att Microsoft skulle välja att inte markera en teknik föråldrad bara på grund av rädsla för inlärningskurvan för MVC. Detta kan vara fallet, men jag ’ är ännu inte övertygad.
• @ P.Brian.Mackey – Jag sa inte ’ att formulärutvecklingen är snabbare än MVC. Du bad att lämna det argumentet ur det. Att argumentera för tid och pengar för att utbilda din personal är ett annat argument. MS vann ’ att markera webbformulär föråldrade av en stor anledning: Företagskunder har spenderat år på att utveckla webbklienter i webbformulär och vann ’ Titta snällt på att behöva investera tid och pengar för att uppdatera.
• @Raynos – Om alla i teamet var skickliga i MVC och ditt företag startade ett nytt projekt är det enda skälet till att jag kunde se någon välja webbformulär personligt val.
• Jag känner till båda teknikerna intimt. Alla mina webbprojekt görs med mvc och arbetar på ett företag där jag har frihet att göra vad som helst som är bäst. Jag väljer alltid MVC.
• Jag började med webbformulär och när jag upptäckte MVC bytte jag till det. Jag vet inte ’ hur någon kan försvara webbformulär. Sidans livscykel och ett formulär för hela sidan? Skojar du? Yahoo sitebuilder var förmodligen den avsedda kunden för det men även de ville inte ’ t det skräpet.

Jag utvecklade ASP. Net WebForms-applikationer i tre år, och efter en dag med en MVC-handledning såldes jag. MVC är nästan ALLTID den bättre lösningen. Varför?

• Sidans livscykel är enklare och effektivare
• Det finns inget sådant som kontroller förutom html-kontroller. Du behöver inte felsöka din produktion för att se vad ASP .Net genererar.
• ViewModels ger dig enorm kraft och undanröjer behovet av att göra manuell kontrollbindning och det eliminerar många fel relaterade till bindning.
• Du kan ha flera formulär på en sida. Detta var en allvarlig begränsning av WebForms.
• Webben är statslös och MVC matchar webbsidans arkitektur närmare. Webblanketter introducerar tillstånd och buggar du har med det genom att introducera ViewState. ViewState är automatisk och fungerar i bakgrunden, så det beter sig inte alltid som du vill ha det.
• Webbapplikationer behöver arbeta med ajax idag. Det är inte acceptabelt att ha fler sidladdningar. MVC gör ajax så mycket bättre, enklare och effektivare med JQuery.
• Eftersom du kan ha flera former på en sida och eftersom arkitekturen är driven av samtal till webbadresser kan du göra skraj saker som ajax ladda en annan form, som en redigeringsformulär till din nuvarande sida med JQuery. När du förstår vad detta låter dig göra kan du enkelt göra fantastiska saker.
• ASP. Net WebForms är inte bara en abstraktion över html, den är extremt komplex. Ibland skulle du få en konstig bugg och kämpa med den mycket längre än behovet. I många fall kunde du faktiskt se vad den gjorde fel men du kan inte göra någonting åt det. Du slutar göra konstiga lösningar.
• WebForms är inte en bra teknik för designers. Designers gillar ofta att arbeta med html direkt. I MVC är det en vy, i WebForms är en halv dags arbete.
• Eftersom webbplattformen utvecklas fort kommer inte WebForms att hålla jämna steg. Det är inte medvetna om nya taggar eller funktioner i HTML5, kommer det fortfarande att göra samma saker om du inte får (ofta) dyra tredjepartskontroller eller väntar på att Microsoft ska ge en uppdatering.
• Kontroller i WebForms begränsar dig på så många sätt. I MVC kan du bara ta ett JQuery-bibliotek och integrera det i dina mallar.

Jag vet att några av problemen ovan har tagits upp i viss utsträckning när WebForms utvecklas, men det var min ursprungliga upplevelse. Sammantaget skulle jag tycka att det är extremt svårt att hitta ett affärsfall för WebForms såvida inte ett projekt redan använder det.

Kommentarer

• +1 för påpekar flera former. Plus det faktum att HTML-webbformulär genererar är oftast inte särskilt SEO-vänligt (som i: stora bitar av viewstate överst på sidan)
• Jag måste hålla 100% med detta svar. I slutet av dagen gör WebForms att göra saker på klientsidan (html / webbläsare) så mycket svårare. Du måste bokstavligen kämpa för att göra någonting gjort. En aspx-sida slutar med så mycket mer kod på grund av serverkontroller än vad en cshtml-sida vanligtvis gör. @ šljaker Om du börjar stänga av ViewState och undviker serverkontroller har du ’ övergett mycket av WebForms vid den tiden. Jag ser inte ’ det argumentet är särskilt övertygande.
• Du kan ha vanliga html-kontroller i WebForms, ingen tvingar dig att använda serverkontroller. Du kan ha ett fullständigt statslöst webbformulär, ingen tvingar dig att använda ViewState. Du kan använda full ajax och jQuery i webbformulär, ingen begränsar dig från att använda jQuery. Du kan implementera URL-routing, ingen tvingar dig att använda statisk filbas-URL. Att manuellt rita en sida med CSS tar tid så mycket som MVC behövs. Du kan designa HTML-sidan direkt på webbformuläret.
• @mjb: Om du inte ’ inte använder serverkontroller, ViewState och så vidare, varför använda WebForms alls när MVC är närmare vad du ’ gör? Det ’ är som att köra en traktor till jobbet men inte göra någon terrängkörning eller använda spade / hacka eller stabilisatorstänger. Vid den punkten varför inte bara använda en bil?
• @Tjaart Det är inte helt rätt att du inte kan ha flera former på ASPNET-sidan.Du kan ha så många formulär som du vill på ASPNET-sidan men du kan bara ha en serverform – formulär med runat = ” server ” attribut.

Jag mailade Scott Guthrie , en MVC-expert på Microsoft. Och förmodligen den mest kvalificerade mannen att svara på den här frågan. Han var snäll att svara:

”Olika kunder letar efter olika programmeringsmetoder och älskar mycket WebForms och tycker att det är fantastiskt. Andra älskar MVC och tycker det är fantastiskt. Det är därför vi investerar i båda. ”

Så för mig säger detta att det inte är en teknisk fråga. Det är mer en ”mjuk fråga”, om du vill. En av personliga preferenser. Detta är i linje med vad flera av er har sagt.

Tack för alla svar.

Kommentarer

• Scott Guthrie uppfann MVC-ramverket för ASP.NET när du flyger tillbaka från London till Seattle 2006/7. När jag tänker på det, uppfann han ganska mycket .NET också ( en.wikipedia.org/wiki/Scott_Guthrie ). Att kalla honom en ” expert ” är en enorm underdrift 😉
• Att ’ ett trevligt politiskt svar från Scott Guthrie. Om han själv investerade i sin egen webbapplikation skulle du ’ se ett MVC-projekt och för allt som inte kunde ’ inte göras i MVC, Silverlight skulle vara reserven. Ta inte ’ detta som en negativ kommentar till WebForms, jag tycker att WebForms är utmärkta för mindre interna applikationer som kan dra nytta av komponenter från tredje part som de som skapats av Telerik. Jag är ’ glad att Microsoft går framåt med båda teknikerna.
• ” Scott Guthrie uppfann MVC-ramverket för ASP .NET när du är på flyg ” Jag tror att det verkligen trivialiserar MVC. Jag känner inte ’ Scott Guthrie, men jag ’ är villig att satsa på att han hade pekulerat hur MVC kan implementeras i ASP.NET ett tag och använde den långa flygningen för att implementera en prototyp med bara ben som ett bevis på konceptet.
• ” Det är därför vi investerar i båda. ” Och när vi ser att webbformulär börjar avta kommer vi nådelöst att släppa det eftersom investering i en slutligen död produkt inte är i vårt bästa affärsintresse.
• Fram till det undervisas inte längre i skolor, på många år, det kommer alltid att vara tillämpligt i näringslivet. Högskolor och gymnasier fortsätter att erbjuda introduktions- och avancerade kurser på vb.net. Det går INTE någonstans !!!

Det här är en gammal fråga med många svar men inga hade svaret hade jag förväntat mig att listas.

Det korta svaret är:

• Använd ASP.NET MVC om du tänker bygga en webbapplikation med modern programmering ordentligt konventioner och industri omfamnade mönster för ASP.NET-plattformen. På nedsidan förväntas du veta hur HTML och resurser på klientsidan (Javascript, CSS) fungerar samt att öka MVC-programmeringstänkandet som har en brant inlärningskurva men når ett plötsligt slut när du förstår.
• Använd ASP.NET webbformulär om du använder eller vill använda en GUI -centric, RAD (Rapid Application Development) , dra-och-släpp-tillvägagångssätt för att prototypa något väldigt snabbt, dvs tryckknapp / datanätbeteende kopplas in inom 15 minuter, och lösningen är inte avsedd att vara något som stöds utvecklare. Eller, Använd ASP.NET webbformulär om du har en bakgrund i GUI eller Windows Forms utveckling och du vill överföra din kunskap till webben.

Men för att titta på detta ordentligt måste du förstå var och en av dem.

ASP.NET Web Forms var Microsofts svar på de som byggt dynamiska webbapplikationer med Visual Basic 6 Ac tiveX-kontroller, VB6-DLL-filer på servern och ASP Classic. Vid den tiden var webbutveckling med dessa Microsoft-verktyg en riktig röra. Tillsammans med hela .NET Framework som var resultatet av Microsoft som i huvudsak gick tillbaka till ritbordet om hur man gör produktiv affärsprogrammering på Windows-stacken, var ASP.NET Web Forms på sin tid fantastiskt och vackert.

Hela tillvägagångssättet var att ge utvecklare det bästa av två världar av något som liknar Windows applikationsutveckling, men med kraften i internettjänster.Tanken var att precis som med en VB6 / WinForms ”Form” (ett fönster) en webbsida är en form (precis som ett fönster, se) , och på det formuläret kan du dra och släppa etiketter, textrutor, datanätverk, knappar och andra saker som VB / WinForms GUI-utvecklare var vana vid.

För att få en knapp att göra något, efter att ha dragit och släppt det, dubbelklickar du bara på det i designern och boomar dig i kodredigeraren och berättar formuläret vad du ska göra när det ”klicket ”händelse händer. Så här skapade Windows GUI-utvecklare programvara med hjälp av GUI -verktyg för VB6 och konkurrerande verktyg, utom nu körs koden på servern! Wow!

Detta var 2002 års teknik. Fantastiskt och vackert i sin tid som svar på internet -aktiverade GUI -lösningar för RAD utveckling , det gav en känsla av kraft till en rörig värld av mjukvaruutvecklare som hade affärsmål som de behövde uppnå.

Tyvärr betonar denna programmeringsmodell så mycket metaforen för Windows GUI-programmering att den bär med sig bördan av dess nödvändiga implementeringsdetaljer , allt besvärande bagage ian essary för att tillgodose händelsens livscykler och ta bort de fula detaljerna i den enkla HTML och skript som dessa dra-och-släpp-komponenter och kontroller skulle mata ut. Och i slutet av dagen var utvecklare som stöder verkliga applikationer oundvikligen tvungna att gräva djupt i dessa komponenter eller skriva sina egna, och följaktligen skulle de slåss strider med denna infrastruktur, strider som skulle lämna bakom högar på högar av grova, dragna hår och tårar.

Säkerhetskopiera. Tvätta händerna. Låt oss titta på affärsproblemet igen. Vilka är våra affärsmål?

Vi behöver bygga och hantera webbapplikationer . Våra begränsningar är att vi har Internet, som sitter på HTTP, HTML, Javascript och CSS, och på servern har vi affärsregler, databaser och en liten handfull fantastiska programmeringsspråk (t.ex. C #). Behöver vi verkligen denna Windows GUI-metafor för att driva vår utvecklingsmetod? Varför kan vi inte bara fokusera på applikationsproblemen och ta bort GUI-metaforerna?

Det är här ASP.NET MVC kommer in. Det började med ett uppror av utvecklare som kallade sig ”Alt.Net” som ville komma tillbaka till rätta och rena programvaruutvecklingsprinciper. Inget mer krångel, bara fokusera på affärsmål och bästa praxis för programvara.

Vad detta verkligen översätter till i det här fallet är:

1. Separation av bekymmer . Till exempel behöver en datakomponent inte veta hur dess data ska återges, och inte heller bör visningskodning vara belastad med konfigurationsdetaljer för databasanslutningar, och på detta sätt kan en utvecklare fokusera på sitt område av intresse vid redigering och testkod.
2. Exponering och fullt stöd för exponering för HTML-relaterade källor och relaterade resurser . I webbformulär är HTML undanstoppad, utvecklare avråds från att krångla med det. I ASP.NET MVC uppmuntras utvecklare snarare att hantera dessa detaljer, det är faktiskt en nödvändighet. Fördelen här är att utvecklaren kan lära sig att uppskatta den rena semantiken för HTML, CSS och script och arbeta med det snarare än emot det.
3. Testbarhet för affärsobjekt . Kontroller och modeller är mycket bättre lämpade för programmatisk enhetstestning, så att implementeringar kan valideras för att uppfylla affärsmålen och ändringar kan verifieras för att de inte kommer att bryta. Med webbformulär var det svårt att testa eftersom komponenter inte var designade för att testas individuellt och hela utvecklingsproduktionen kretsade kring sidformulär och deras livscykler med händelserna med affärslogik och presentationslogik djupt sammanflätade.

Observera att HTML redan är ett mycket högt markeringsspråk, liksom Javascript är ett programmeringsspråk på hög nivå. Hela historien skulle ha varit annorlunda om vi hade att göra med församlingsspråk och C.

Utökas till nummer 2, då är ett annat mål med ASP.NET MVC att göra det möjligt för utvecklare att organisera frontend-detaljerna för ”visa” delen av deras lösningar och dra nytta av den rika grunden som resten av branschen har byggt på front-end-klientplattformen.

Du kommer att upptäcka att ASP.NET MVC-utvecklare känner sig hemma med rika Javascript-bibliotek och malltekniker på klientsidan utan att kämpa med serversidan. Detta var ursprungligen inte fallet med ASP.NET webbformulär, eftersom webbformulär inte vill att du ska titta på HTML eller skript alls, förutom om du verkligen måste , i vilket fall, se upp, det är inte för svaga hjärtan .

Kommentarer

• Detta är ett bra svar, men # 1 och # 2 är fel (WF kräver ingen komponent för att veta var dess data kommer från, det är ett alternativ och du har alltid lagt till HTML i dina ASPX-filer för att stödja asp-taggarna du gör. Du har aldrig behövt gräva djupt och bekämpa kontrollerna om du inte försökte få tillgång till en ASP-funktion som inte är avsedd för utvecklare interaktion. De stora poängen är testbarhet och designmönster.)

Jag är en fullständig och total konverterare till ASP.NET MVC och har inte tittat tillbaka, som sagt att jag fortfarande måste underhålla flera mycket stora WebForms-appar. Här är min åsikt om det:

WebForms
Använd dessa när du har något allvarligt tungt liv saker att göra med galler. Rutnätkontrollerna är verkligen mycket trevliga när du har en enkel dataset som passar bra i tabellformat och du vill ge ett enkelt sätt för användare att uppdatera poster. Ja, jag vet att MVC 4 har en riktigt snuskig Ajax-listatyp som du kan använda som fungerar bra men i vår verksamhet behöver vi ofta få igång något igår och goda gammaldags rutnät fungerar bra och användarna är glada att vara kunna flik över ett rutnät med glädje. För mig är det verkligen det bästa med WebForms för mig, men som Ryan påpekade kan WebForms vara en stor tidsröra eftersom du spelar båda sidor av staketet från en smidig kod-bak fil. Det kan vara både en ros och en tagg samtidigt för att hålla alla dina controller-typ grejer blandade med dina vyer.

MVC
Använd detta när du verkligen vill rulla din egen och du har möjlighet att starta en applikation från grunden. Att ha en tydligt definierad MVC-applikation är lite mer arbete att komma igång med, men dess fördelar med underhåll uppväger de ursprungliga installationskostnaderna. Om du vill göra intressanta Ajax-interaktioner, föredrar du att skriva din modell med kod, som rena webbadresser och rutter, och kunna kontrollera hela flödet av din app, så är det här definitivt vägen att gå. till först men jag tycker att det är det bättre alternativet för greenfield-appar.

Sammanfattningsvis kommer det för mig att gå ner till nät och! 🙂

Kommentarer

• +1 för den fina bilden levererad med ” som spelar båda sidor av staket från en snygg kod bakom filen ”.
• Mycket hjälpsam den här. Jag ’ gör en väldigt tung nätbaserad app och jag ’ har uteslutit silverlight, xbap och det var nere i en show ner mellan dessa två.

Min erfarenhet:

• Skrev CakePHP-projekt under ett år.
• Slutförde ett medelstort webbformulärsprojekt under sex månader.
• Arbetade med ett Windows Forms-projekt i tre år.

Efter den upplevelsen försökte jag skriva en annan app med webbformulär och blev frustrerad efter att ha kämpat i ungefär en dag med hur webbformulär försöker skydda utvecklaren från verkligheten att de utvecklar en applikation som använder html, javascript och css.

Jag försökte sedan ut MVC och hade mer direkt kontroll över produktionen (och lite erfarenhet av MVC-paradigmet från CakePHP) Jag kunde slutföra den enkla appen precis som jag ville ha den på ungefär 1/2 om dagen.

Tillgängligheten av kraftfulla UI-ramar som jQuery väldigt mycket eli minar överklagandet att ge upp direkt kontroll över utdata till förmån för att använda ofta skrymmande förbyggda UI-komponenter.

Kommentarer

• @JimG – Uhh , allt som involverar en person som registrerar poster utan intressanta kopplingar till en databas, och att den personen eller någon annan läser / skriver ut dem vid någon annan punkt kan i grunden ställas med hjälp av ett MVC-ramverk. Beviljas, det är inte ’ de flesta appar, men det ’ är en hel del mer än du kan göra med formulär. Jag antar att din -1 bevisar min poäng.
• Att ’ är 1/4 av en dag.
• Men om kraven uppgår till ” Jag behöver en app med två roller, en för att spela in lite information, den andra för att titta på den, och jag behöver inte ’ t bryr dig hur det ser ut. ” Då, ja, att ’ är ganska genomförbart.
• jag är ledsen, men att utveckla en webbformsapp för att mata in data och visa data är så enkelt att det kan göras på några timmar. att skapa strukturen för en MVC-app, styrenheter, vyer och åtgärder, skulle ta samma tid, men kommer inte till en färdig produkt.
• @ Dementic Vanligtvis för en enkel MVC-app bygger man modeller, sedan byggnadsställningar och vyer och / eller genererar byggnadsställningar / vyer. Inget riktigt tidskrävande där.

Jag föredrar webbformulär eftersom min bakgrund är Windows-utveckling.

Utvecklingshastighet är en nyckelfråga, och jag kan enkelt skicka ett problem till någon i Indien för att fixa över natten med formulär, även om jag har ett hastighetsproblem på en sida, en riktigt bra bok om asp.net hastighet är praktiskt (Rick Kiessig är mannen).

webbformulär är för ex windows människor mvc är för webbfolk

men i den moderna världen, där Rick har skrivit en fantastisk bok , med servrar som ökar i hastighet dagligen och billiga kodare i Indien, ja, webbformulär har kanten

Mina 2 cent är att alltid använda ASP.NET MVC för nya projekt om du har möjlighet. Enligt min mening är webbformulär inte ett bra sätt att utveckla webbappar, period.

Jag tycker att det är dåligt att ta bort grundläggande REST, hela postback-modellen är dålig, hur html / css lämnas med en tillit på GUI-redigeraren är dålig, betoningen på saker som guider och GUI för att ställa in saker är dåligt, webbadresserna är dåliga.

Kommentarer

• kan du förklara mer detaljerat varför du tror det?
• Jag tror att det är att återvinna grundläggande REST är tillbaka, hela postback-modellen är tillbaka, hur html / css lämnas med ett beroende av GUI-redigeraren är dåligt , betoningen på saker som guider och GUI för att ställa in saker är dåligt, webbadresserna är dåliga osv. osv.

Jag har inte sett denna överväganden framförts bland de befintliga 15 svaren på den här tråden än, men jag tror att den ”Det är värt att överväga.

Enligt min erfarenhet liknar Web Forms mer Win Forms och WPF än MVC är. Med tanke på detta tror jag att man kan överväga att välja webbformulär när teamet har mest erfarenhet av den typen av teknik, eller när webbformulärsprojektet kommer att leverera ett gränssnitt till samma datamängd som ett befintligt (eller samtidigt utvecklat) Win Forms WPF-projekt. Genom att göra det kan utvecklare lättare korsa projekt eftersom applikationslogik kan vara ganska lika mellan de två.

Som andra svar har påpekat liknar utvecklingen av MVC-ramarna mer webbutveckling i Ruby, PHP, Python etc än dess motsvarigheter från Microsoft; så naturligtvis kan valet av MVC påverkas av lagens erfarenhet inom dessa områden, tillsammans med de faktorer som lämnas in i andra svar.

Kommentarer

• + 1 Visst ett rimligt argument för webbformulär. Min rädsla är att team följer denna inställning för att undvika att lära sig nya saker. MVC är fylld med många mönster som kan vara obekanta för ett lag. Att lära sig dessa typer av mönster och implementera dem leder till bättre överensstämmelse med SOLID-principer som översätter till bättre övergripande underhållsförmåga. Dessa beprövade tekniker är också den verkliga nyckeln till återanvändbarhet.

Vår anledning att inte gå till MVC för några år sedan var det en omogen teknik från Microsoft. Under de senaste åren har vi nu en mer mogen version (4) och MS verkar ha räknat vart de ska med detta.Vi är emellertid fortfarande ovilliga att utveckla stora LOB-appar med MVC eftersom de funktioner vi vill använda i version 4 kräver en Windows 2012-server (åter webbuttag via IIS8). Jag räknar med att om ytterligare ett år kommer vi att acceptera MVC mer eftersom förhoppningsvis fler tredjepartskontroller kommer att finnas tillgängliga, tekniken kommer att ha lösts och vi kommer att ha infrastrukturen för att stödja den.

Kommentarer

• Har du något emot att lista några av dessa funktioner som du säger kräver Windows Server 2012?

Detta beslut beror på dina preferenser, på dina krav eller till och med på din kunskap och erfarenhet.

Tiden för träning av lärande MVC eller tid att få en leverans. Allt detta är viktigt för att välja en eller annan aproach.

Är inte det att man är bättre än en annan, helt enkelt har både aproach eller ramar fördelar och nackdelar.

Personligt jag gillar MVC 3, Jag rekommenderar att du försöker få din egen upplevelse, men jag måste säga att programmet i MVC är ett rent, roligt, flexibelt, utdragbart, säkert och strukturerat sätt.

Hälsningar,

Den enda anledningen till att jag skulle välja WebForms istället för MVC är att du har mycket mer tredjeparts-UI-kontroller för WebForms än MVC. Jag väljer MVC för att jag jobbade för mycket med WebForms och jag vill jobba med något nytt / nytt, men ändå från MS shop 🙂

I grund och botten hindrar ingenting dig att stänga av viewstate i WebForms och använda ViewModels och om / för loopar istället för modellbindning och serversides kontroller.

Är det här WebForms eller MVC-kod:

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

Den enda begränsningen jag hittade i WebForms är att om du använder Dependency Injection / Inversion of Kontroll, du kan inte få konstruktörinjektion eftersom WebForms-sidor måste ha en parameterlös konstruktör, så du måste använda fastighetsinjektion. Är det verkligen så stort?

ASP.NET MVC är verkligen ett svar på Ruby, och det nya, trendiga och (IMO) bättre sättet att koppla bort webbläsaren (klienten) från servern så mycket som möjligt.

ASP.NET-webbformulär ger dig mycket kontroll över klienten från serversidan med direkt åtkomst till i stort sett allt. I huvudsak är din uppfattning och styrenhet en i samma sak, vilket ger dig mycket kraft, och oftast mycket röra.

ASP.NET MVC separerar vyn och styrenheten genom att lossa den täta kopplingen av en .aspx-fil och .aspx.cs-filen som medföljer dem i webbformulär.

I huvudsak är skillnaden att du har mycket mer (vanligtvis all) bearbetning för att visa data till visningsfilen och lämnar affärslogiken och resten i styrenheten, och håller dem båda renare enligt konvention, men också med mindre åtkomst till varandra än webbformulär tillåter.

Kommentarer

• Så NÄR ska webbformulär gynnas framför MVC? Detta svarar inte på originalaffischfrågan.
• @WeekendWarrior – När du vill ha mer åtkomst till klientservern på serversidan väljer du webbformulär. Om du vill ha mer frikoppling av klienten / servern i din kod väljer du MVC. I slutet av dagen gör de båda exakt samma sak. Omdirigeringsfilter gör samma sak som MVC-webbadresserna och du kan flytta webbformulärkoden bakåt till en separat mittnivå för att koppla bort den mer. weblogs.asp.net/scottgu/archive/2010/01/24/…
• När det gäller din tredje punkt hamnar den affärslogiken i .aspx.cs-filen – jag tror att detta är utvecklarnas fel. Det ’ är inte / ska / vara där. I webbformulär är .aspx ” vy ”, .aspx.cs är ” controller ” ekvivalent, avsedd att bearbeta koden som bara hänför sig till användargränssnittet genom att polla ett affärslag eller grovkornat affärsfasadlager. Det faktum att människor lägger affärslogik i .aspx.cs är bara dålig programmering. De kunde också sätta affärslogik rätt i vyn i MVC! MVC tvingar inte ’ att separera dessa saker.
• I grund och botten har han mer rätt än andra svar som läggs upp här. ASP.net är grundidén bakom en modulär webbteknikfamilj som skapats av Microsoft. ASP.net MVC-modulen kan vara en tidsmässig hype men det är verkligen inte den sista, allt börjar med ASP.net, så när ska man välja ASP.net, om du inte tror att MVC inte är din sak, kanske mer till något annars OWIN eller …, något mer avancerat, eller skapat en egen ram för dina uppgifter. Du kanske inte ens behöver ASP.MVC och hoppa över den och gå Owin eller Katana, men tills du använder asp.net

Enligt min mening är de tillräckligt relaterade och har ungefär samma funktioner som det borde komma ner till preferens.

En bra WebForms-utvecklare kan producera en produkt lika kraftfull som en stor MVC-utvecklare. Men den stora WebForms-utvecklaren som försöker tvinga sig själv att anta MVC kommer att komma kort. Samma sak gäller för en fantastisk MVC-utvecklare som ger WebForms ett skott.

De är inte helt separata enheter, och så länge Microsoft fortsätter att stödja båda, tror jag att du kommer att fortsätta se en blandad grupp av exceptionella utvecklare för var och en.

Allt handlar om personligt val, förutsatt att vi alla är skickliga med den teknik vi använder. Jag har använt WebForms designmetoden i många år, och jag måste säga att den enda nackdelen är att på grund av det förenklade tillvägagångssättet tar många människor inte sin tid att hitta den stora kapaciteten.

Jag använde nyligen MVC för att slutföra ett projekt, och även om jag ganska gillar designmetoden för applikationsutveckling (som ger dig mer kontroll, rena webbadresser, SOC, etc), det finns verkligen inte mycket det ger , att WebForms inte kan. Faktum är att framväxten av jQuery och dess samarbete med WebForms (liksom MVC) har gjort dessa argument mindre problem. Och när människor talar om att separera bekymmer som en fördel MVC har framför MVP, frågar jag dem hur mycket de känner till objektorienterad programmering och hur mycket de använder principen om abstraktion och polymorfism.

Jag är för närvarande bekväm med att använda båda teknikerna och jag väljer och väljer utifrån situationen. Uppriktigt sagt är det upp för dig, men sanningen kvarstår att inte alla tar sig tid att lära sig djupt vad en viss teknik kan.

Kommentarer

• Ditto on webbformulärens stora möjligheter. De flesta människor ser träningshjulen för webbformulär och jämför detta med MVC.
• Det är lite meningsfullt att lära sig en abstraktion ovanpå HTML och Javascript i vår tid (även i 2013). Det ’ gör dig inte bra för dina framtida möjligheter. HTML och Javas cript är bara bra som det är. Att bekämpa det är en förlorande strid.

När jag står inför ett programmeringsproblem tittar jag ofta på webben för svar. Webblanketter har massor av information / komponenter för att göra nästan vad som helst. I MVC på grund av färre källor online och de lager av abstraktioner som behövs för att något ska fungera har det satt en gräns för saker som jag en gång kunde göra. MVC-total dödar min produktivitet som utvecklare medan det inte är med webbformulär. Så nu håller jag fast vid webbformulär tills MVC har mognat tillräckligt för att ersätta det.

Tja, WebForms har fler inlärningsresurser tillgängliga (helt enkelt på grund av att det är äldre) och det är därför mer troligt att nya programmerare som inte ”vet” vet ” information om denna äldre teknik i motsats till de nyare sakerna som MVC.

Äldre / erfarna programmerare är äldre och kommer att vara mer skickliga i den äldre tekniken på grund av att de har programmerat in den längre än de har i den nyare.

Om du inte kan spendera pengar och ansträngningar för att få dina killar lika skickliga i MVC som de är i WebForms-applikationer, kommer du utan tvekan att försöka hålla ut uppgraderingen till den nya plattform så länge som möjligt.

Så det ger flera logistiska problem: Går fördelarna med MVC upp till kostnaden när det gäller lägre kvalitet och distributionstid? Om jag har en webbplats skriven helt i WebForms, skulle det vara värt ansträngningen och pengarna att integrera MVC i den?

Som sagt av en tidigare kommentator hindrar MVC dig också från att uppnå samma nivå av gränssnitt med styrenheten som du skulle kunna göra med WebForms. Medan jag är allt för att ”hålla användaren från att fylla upp saker / lära sig”, kan det fortfarande vara orimligt besvärligt för team att distribuera / implementera ett program som fanatiskt håller fast vid det paradigmet för allt de skriver.

Jag tror att klyftan mellan dessa två tekniker inte är så stor som den var.

• Webblanketter kan använda den dirigeringsmotor som MVC använder (eller något mycket liknande).
• Skripthanteraren kan kombinera skript, ladda från en CDN och till och med fördröja laddningen av skript.

För att direkt svara på din fråga tror jag att det kommer ner till preferens och / eller vad projektet är. De har båda ett väsentligt annorlunda tillvägagångssätt för utveckling. Personligen har jag arbetat med att gå mot MVC, men tycker fortfarande om att arbeta med webbformulär. Jag tror att svaret på huruvida du ska använda MVC eller webbformulär är att du ska bestämma genom att uppleva båda teknikerna.

Kommentarer

• Webblanketter och MVC rekommenderar en radikalt annorlunda webbutvecklingsinställning, detta är viktigt , få utvecklare avviker från ” standard ”. Båda kan dock användas för att uppnå samma sak.