Hvornår skal jeg favorisere ASP.NET WebForms frem for MVC

Webforms vs. MVC ser ud til at være et varmt emne lige nu. Alle, jeg kender, kalder MVC for at være den næste store ting. Fra mine små pletter i det virker det ok, men nej, jeg tror ikke, det vil være slutningen på webformularer.

Min begrundelse og begrundelsen for, hvorfor webformularer vælges frem for MVC, har mere at gøre med et forretningsperspektiv snarere end det ene er bedre end det andet.

Tid / penge er de største grunde til, at webformularer vælges frem for MVC.

Hvis det meste af dit teamet kender webformularer, og du har ikke tid til at få dem til at køre hurtigere på MVC, den kode, der bliver produceret, er muligvis ikke kvalitet. At lære det grundlæggende ved MVC og derefter hoppe ind og lave den komplekse side, du skal gøre, er meget forskellige ting. Læringskurven er høj, så du skal indregne det i dit budget.

Hvis du har et stort websted skrevet alle i webformularer, er du måske mere tilbøjelig til at oprette nye sider i webformularer, så du ikke ” Jeg har ikke to meget forskellige sider på dit websted.

Jeg siger ikke, det er en alt eller intet tilgang her, men det gør din kode sværere at vedligeholde, hvis der er en opdeling af begge , især hvis ikke alle i teamet er fortrolige med MVC.

Mit firma lavede for nylig tre testsider med MVC. Vi satte os ned og designede dem. Et problem, vi stødte på, er at de fleste af vores skærme har visnings- og redigeringsfunktionaliteten på den samme side. Vi endte med at have brug for mere end en formular på siden. Ingen biggy, bortset fra da ville vi ikke bruge vores masterside. Vi var nødt til at modernisere det, så både webformsiderne og MVC-siderne kunne bruge den samme masterside til fælles udseende. Nu har vi et ekstra lag af indlejring.

Vi havde brug for at oprette en helt ny mappestruktur til disse sider, så den fulgte den korrekte MVC-adskillelse.

Jeg følte, at der var for mange filer til 3 sider, men det er min personlig mening.

Efter min mening vælger du webformularer frem for MVC, hvis du ikke har tid / penge til at investere i at opdatere dit websted til at bruge MVC. Hvis du gør en halv arsed tilgang til dette, det vil ikke være bedre end de webformularer, du har nu. Værre, du kan endda indstille denne teknologi til fiasko i din virksomhed, hvis den er ødelagt, da øverste ledelse måske ser det som noget ringere end det, de ved.

Kommentarer

• Dette er et godt svar. Jeg gav dig +1, fordi dine personlige oplevelser er værdsat. Men dette er fiasko på grund af manglende erfaring / dygtighedssæt hos udviklerne, som jeg bad om at undgå Jeg er ikke overbevist om, at Microsoft ville vælge ikke at markere en teknologi, der er forældet, simpelthen på grund af frygt for indlæringskurven for MVC. Dette kan være tilfældet, men jeg ‘ er endnu ikke overbevist.
• @ P.Brian.Mackey – Jeg sagde ikke ‘ at formudvikling er hurtigere end MVC. Du bad om at lade dette argument ude af det. At argumentere for tid og penge til at træne dit personale er et andet argument. MS vandt ‘ t markerer webformularer forældede af en stor grund: Virksomhedsklienter har brugt år på at udvikle webklienter i webformularer og vandt ‘ t se venligt på at skulle investere tid og penge for at opdatere.
• @Raynos – Hvis alle i teamet var dygtige til MVC, og din virksomhed startede et nyt projekt, er den eneste grund til, at jeg kunne se nogen vælge webformularer, det personlige valg.
• Jeg kender begge teknologier tæt. Alle mine webprojekter udføres med mvc og arbejder i et firma, hvor jeg har fri regeringstid til at gøre, hvad der er den bedste tilgang. Jeg vælger altid MVC.
• Jeg startede med webformularer, og når jeg først opdagede MVC, skiftede jeg til det. Jeg ved ikke ‘ hvordan nogen kunne forsvare webformularer. Side livscyklus og en formular for hele siden? Laver du sjov med mig? Yahoo sitebuilder var sandsynligvis den tiltænkte kunde til det, men selv de ‘ t ønskede det skrammel.

Jeg udviklede ASP .Net WebForms applikationer i 3 år, og efter en dags udførelse af en MVC tutorial blev jeg solgt. MVC er næsten ALTID den bedre løsning. Hvorfor?

• Sidens livscyklus er enklere og mere effektiv
• Der er ikke sådan noget som kontroller udover html-kontroller. Du behøver ikke at fejle din output for at se, hvad ASP .Net genererer.
• ViewModels giver dig en enorm styrke og undgår behovet for at udføre manuel kontrolbinding, og det eliminerer mange fejl i forbindelse med binding.
• Du kan have flere formularer på en side. Dette var en alvorlig begrænsning af WebForms.
• Internettet er statsløst og MVC matcher arkitekturen på nettet nærmere. Webformularer introducerer tilstand og fejl du har det ved at introducere ViewState. ViewState er automatisk og fungerer i baggrunden, så det opfører sig ikke altid som du vil have det.
• Webapplikationer skal arbejde med ajax i disse dage. Det er ikke acceptabelt at have flere sider indlæst mere. MVC gør ajax så meget bedre, lettere og mere effektivt med JQuery.
• Fordi du kan have flere former på en side, og fordi arkitekturen er drevet af opkald til webadresser, kan du gøre funky ting som ajax indlæse en anden form, som en redigeringsformular på din nuværende side ved hjælp af JQuery. Når du først er klar over, hvad dette giver dig mulighed for, kan du gøre fantastiske ting let.
• ASP. Net WebForms er ikke kun en abstraktion over html, det er ekstremt kompliceret. Nogle gange får du en underlig fejl og kæmper med den meget længere end behovet er. I mange tilfælde kunne du faktisk se, hvad den gjorde forkert men du er ikke i stand til at gøre noget ved det. Du ender med at gøre underlige løsninger.
• WebForms er ikke en god teknologi for designere. Designere kan ofte lide at arbejde med html direkte. I MVC er det en visning i WebForms er en halv dags arbejde.
• Da webplatformen udvikler sig, holder WebForms ikke med. Det er ikke klar over nye tags eller funktioner i HTML5, gengiver det stadig de samme ting, medmindre du får (ofte) dyre tredjepartskontrol eller venter på, at Microsoft udsteder en opdatering.
• Kontroller i WebForms begrænser dig på så mange måder. I MVC kan du bare få fat i et JQuery-bibliotek og integrere det i dine skabeloner.

Jeg ved, at nogle af ovenstående spørgsmål er blevet behandlet i nogen grad, efterhånden som WebForms udvikler sig, men det var min oprindelige oplevelse. Alt i alt ville jeg finde det ekstremt svært at finde en business case til WebForms, medmindre et projekt allerede bruger det.

Kommentarer

• +1 for påpege flere former. Plus det faktum, at HTML-webformularer genererer, er for det meste ikke særlig SEO-venlig (som i: store klumper af viewstate øverst på siden)
• Jeg er enig 100% i dette svar. I slutningen af dagen gør WebForms ting, der gør tingene på klientsiden (html / browser) så meget hårdere. Du skal bogstaveligt talt kæmpe for rammerne for at få noget gjort. En aspx-side ender med så meget mere kode på grund af serverkontrol end en cshtml-side typisk gør. @ šljaker Hvis du begynder at deaktivere ViewState og undgår serverkontroller, har du ‘ forladt meget af WebForms på det tidspunkt. Jeg ser ikke ‘ dette argument er særlig overbevisende.
• Du kan have almindelige html-kontroller i WebForms, ingen tvinger dig til at bruge serverkontroller. Du kan have fuld statsløs webform, ingen tvinger dig til at bruge ViewState. Du kan bruge fuld ajax og jQuery i webformularer, ingen begrænser dig fra at bruge jQuery. Du kan implementere URL-routing, ingen tvinger dig til at bruge basisk URL til statisk fil. Manuel tegning af en side med CSS bruger den tid, så meget som MVC har brug for. Du kan designe HTML-siden direkte på webformularen.
• @mjb: Hvis du ikke ‘ ikke bruger serverkontroller, ViewState og så videre, hvorfor bruge WebForms overhovedet, når MVC er tættere på det, du ‘ laver? Det ‘ er som at køre en traktor på arbejde, men ikke udføre terræn eller bruge skovl / hakke eller stabilisatorstænger. På det tidspunkt hvorfor ikke bare bruge en bil?
• @Tjaart Det er ikke helt rigtigt, at du ikke kan have flere former på ASPNET-siden.Du kan have så mange formularer som du vil på ASPNET-siden, men du kan kun have en serverformular – form med runat = ” server ” attribut.

Jeg mailede Scott Guthrie , en MVC-ekspert hos Microsoft. Og sandsynligvis den mest kvalificerede mand til at besvare dette spørgsmål. Han var venlig nok til at svare:

“Forskellige kunder ser efter forskellige programmeringsmetoder og elsker meget WebForms og synes det er fantastisk. Andre elsker MVC og synes det er fantastisk. Derfor investerer vi i begge dele. “

Så for mig siger dette, at det ikke er et teknisk problem. Det er mere af et “blødt problem”, hvis du vil. En af personlige præferencer. Dette er i tråd med, hvad flere af jer har sagt.

Tak for alle svarene.

Kommentarer

• Scott Guthrie opfandt MVC-rammen for ASP.NET under en flyvning tilbage fra London til Seattle i 2006/7. Når jeg tænker på det, opfandt han stort set også .NET ( da.wikipedia.org/wiki/Scott_Guthrie ). At kalde ham en ” ekspert ” er en enorm underdrivelse 😉
• At ‘ et godt politisk svar fra Scott Guthrie. Hvis han selv investerede sin egen webapplikation, ville du ‘ se et MVC-projekt og for alt, hvad der ikke kunne ‘ ikke gøres i MVC, Silverlight ville være et tilbagefald. Don ‘ t tage dette som en kommentar negativ til WebForms, jeg synes WebForms er fantastisk til mindre scoped interne applikationer, der kan drage fordel af tredjepartskomponenter som dem, der er oprettet af Telerik. Jeg er ‘ glad for, at Microsoft bevæger sig fremad med begge teknologier.
• ” Scott Guthrie opfandt MVC-rammen til ASP .NET under en flyvning ” Jeg tror, det virkelig bagatelliserer MVC. Jeg kender ‘ Scott Guthrie, men jeg ‘ er villig til at satse på, at han havde peculeret, hvordan MVC muligvis blev implementeret i ASP.NET i et stykke tid og brugte den lange flyvning til at implementere en prototype med bare knogler som et bevis på konceptet.
• ” Derfor investerer vi i begge dele. ” Og når vi ser, at webformularer begynder at falde, vil vi nådesløst droppe det, fordi investering i et i sidste ende dødt produkt ikke er i vores bedste forretningsinteresse.
• Indtil det undervises ikke længere i skoler i mange år, det vil altid være anvendeligt i erhvervslivet. Gymnasier og gymnasier tilbyder fortsat introduktionskurser og avancerede kurser på vb.net. Det går IKKE overalt !!!

Dette er et uaktuelt spørgsmål med mange svar, men ingen havde svaret, ville jeg have forventet at blive anført.

Det korte svar er:

• Brug ASP.NET MVC, hvis du har til hensigt at opbygge en webapplikation korrekt med moderne programmering konventioner og industri omfavnede mønstre for ASP.NET-platformen. På undersiden forventes det, at du ved, hvordan HTML- og klientsidens ressourcer (Javascript, CSS) fungerer såvel som rampe op på MVC-programmeringstænkningen, som har en stejl indlæringskurve, men når en pludselig slutning, når den først er taget fat.
• Brug ASP.NET-webformularer, hvis du bruger eller vil bruge en GUI -centric, RAD (Rapid Application Development) , træk-og-slip-tilgang til prototyping af noget meget hurtigt, dvs. trykknap / datagitteradfærd kablet op inden for 15 minutter, og løsningen er ikke beregnet til at være noget understøttet af Eller, Brug ASP.NET-webformularer, hvis du har en baggrund i GUI eller Windows Forms-udvikling, og du ønsker at overføre din viden til internettet.

Men for at se på dette korrekt, skal du forstå historien for hver.

ASP.NET Web Forms var Microsofts svar på dem, der havde bygget dynamiske webapplikationer ved hjælp af Visual Basic 6 Ac tiveX-kontroller, VB6-DLLer på serveren og ASP Classic. På det tidspunkt var webudvikling ved hjælp af disse Microsoft-værktøjer et rigtigt rod. Sammen med hele .NET Framework, der var output fra Microsoft, gik i det væsentlige tilbage til tegnebrættet om, hvordan man laver produktiv forretningsprogrammering på Windows-stakken, var ASP.NET Web Forms på sin tid fantastisk og smukt.

Hele fremgangsmåden var at give udviklere det bedste fra begge verdener af noget, der ligner meget Windows-applikationsudvikling, men med kraften fra internettjenester.Ideen var, ligesom med en VB6 / WinForms “Form” (et vindue) en webside er en form (ligesom et vindue, se) , og i den form kunne du trække og slippe etiketter, tekstbokse, datagitter, knapper og andre ting, som VB / WinForms GUI-udviklere var vant til.

For at få en knap til at gøre noget, efter at du har trukket og sluppet det, skal du bare dobbeltklikke på det i designeren og bombe dig “i kodeeditoren og fortælle formularen, hvad du skal gøre, når det” klik “begivenhed sker. Dette var præcis, hvordan Windows GUI-udviklere oprettede software ved hjælp af GUI -værktøj til VB6 og konkurrerende værktøjer, undtagen nu koden udføres på serveren! Wow!

Dette var teknologien fra 2002. Fantastisk og smuk i sin tid som et svar på internettet -aktiverede GUI -løsninger til RAD -udvikling , det bragte en følelse af magt til en rodet verden af softwareudviklere, der havde forretningsmål, som de havde brug for at nå.

Desværre understreger denne programmeringsmodel så meget metaforen til Windows GUI-programmering, at den bærer byrden af dens nødvendige implementeringsdetaljer , al besværlig bagage ian essay for at imødekomme begivenhedens livscyklusser og fjerne de grimme detaljer i den enkle HTML og script, som disse træk-og-slip-komponenter og kontrolelementer ville sende. Og i slutningen af dagen måtte udviklere, der understøtter rigtige applikationer, uundgåeligt grave dybt ned i disse komponenter eller skrive deres egne, og følgelig kæmpede de kampe med denne infrastruktur, kampe der ville efterlade bunker på bunker af krydset, trukket hår og tårer.

Sikkerhedskopier. Vask hænder. Lad os se på forretningsproblemet igen. Hvad er vores forretningsmål?

Vi har brug for at opbygge og administrere webapplikationer . Vores begrænsninger er, at vi har World Wide Web, som sidder på HTTP, HTML, Javascript og CSS, og på serveren har vi forretningsregler, databaser og en lille håndfuld gode programmeringssprog (f.eks. C #). Har vi virkelig brug for denne Windows GUI-metafor for at drive vores udviklingsmetode? Hvorfor kan vi ikke bare fokusere på applikationsproblemerne og fjerne GUI-metaforerne?

Det er her ASP.NET MVC kommer ind. Det startede med et oprør af udviklere, der kaldte sig “Alt.Net”, der ønskede at vende tilbage til de rette og rene softwareudviklingsprincipper. Du behøver ikke mere ophidselse, bare fokusere på forretningsmål og bedste praksis for software.

Hvad dette virkelig oversættes til i dette tilfælde er:

1. Adskillelse af bekymringer . For eksempel behøver en datakomponent ikke at vide, hvordan dens data skal gengives, og visningsopmærkning bør heller ikke være behæftet med konfigurationsdetaljer for databaseforbindelser, og på denne måde kan en udvikler fokusere på sit bekymringsområde, når man redigerer og testkode.
2. Eksponering og fuld understøttelse af eksponering for den nitty gritty af HTML og relaterede ressourcer . I webformularer gemmes HTML væk, udviklere frarådes at stå på med det. I ASP.NET MVC tilskyndes udviklere snarere til at administrere disse detaljer, faktisk er det en nødvendighed. Fordelen her er, at udvikleren kan genlære at værdsætte den rene semantik af HTML, CSS og script og arbejde med det snarere end imod det.
3. Testbarhed af forretningsobjekter . Controllere og modeller er meget bedre egnet til programmatisk enhedstest, så implementeringer kan valideres for at opfylde forretningsmål, og ændringer kan verificeres, så de ikke går i stykker. Med webformularer var det vanskeligt at teste, da komponenter ikke var designet til at blive testet individuelt, og hele udviklingsoutputtet drejede sig om sideformularer og deres livscyklus med begivenheder med muck af forretningslogik og præsentationslogik dybt sammenflettet.

Bemærk, at HTML allerede er et meget højt niveau markup sprog, ligesom Javascript er et programmeringssprog på højt niveau. Hele historien ville have været anderledes, hvis vi havde at gøre med forsamlingssprog og C.

Udvidelse til nr. 2, så er et andet mål med ASP.NET MVC at gøre det muligt for udviklere at organisere frontend-detaljerne i “se” -delen af deres løsninger og drage fordel af det rige fundament, som resten af branchen har bygget på front-end-klientplatformen.

Du finder ud af, at ASP.NET MVC-udviklere føler sig hjemme ved at bruge rige Javascript-biblioteker og skabelonteknikker på klientsiden uden at kæmpe med serversidesarkitekturen. Dette var oprindeligt ikke tilfældet med ASP.NET-webformularer, fordi webformularer overhovedet ikke vil have dig til at se på HTML eller scriptet, undtagen hvis du virkelig skal , i hvilket tilfælde pas på, det er ikke for svag af hjertet .

Kommentarer

• Dette er et godt svar, men nr. 1 og # 2 er forkert (WF kræver ikke en komponent for at vide, hvor dens data er kommer fra, det er en mulighed, og du har altid tilføjet HTML til dine ASPX-filer for at understøtte de asp-tags, du gengiver. Du har aldrig haft brug for at grave dybt og bekæmpe kontrollerne, medmindre du forsøgte at få adgang til en ASP-funktion, der ikke er beregnet til udvikler interaktion. De store punkter er testbarhed og designmønster.)

Jeg er en komplet og total konvert til ASP.NET MVC og ikke har set tilbage, når det er sagt, at jeg stadig skal vedligeholde flere meget store WebForms-apps. Her er min mening om det:

WebForms
Brug disse, når du har et seriøst tungt liv ting at gøre med gitre. Gitterkontrollerne er virkelig meget rart, når du har et simpelt datasæt, der passer fint i et tabelformat, og du vil give en enkel måde for brugerne at opdatere poster. Ja, jeg ved, at MVC 4 har en rigtig snazzy Ajax liste-type ting, som du kan bruge, der fungerer godt, men i vores forretning er vi ofte nødt til at få noget i gang i går, og gode gammeldags net fungerer godt, og brugerne er glade for at være i stand til at flige over et gitter med glæde. For mig er det virkelig den bedste ting ved WebForms for mig; men som Ryan påpegede, kan WebForms være et stort rod, fordi du spiller begge sider af hegnet fra en smidig kode bag fil. Det kan være både en rose og en torn på samme tid at holde alle dine controller-type ting blandet med dine synspunkter.

MVC
Brug dette, når du virkelig vil rulle dit eget, og du har mulighed for at starte en applikation fra bunden. At have en klart defineret MVC-applikation er lidt mere arbejde at komme i gang med, men fordelene ved vedligeholdelse opvejer de oprindelige installationsomkostninger. Hvis du vil lave interessante Ajax-interaktioner, foretrækker du at skrive din model med kode, som f.eks. Rene webadresser og ruter, og være i stand til at kontrollere hele strømmen af din app, så er dette helt sikkert vejen at gå. Det tager lidt at vænne sig til først, men jeg synes, det er den bedre mulighed for greenfield-apps.

Afslutningsvis for mig kommer det ned på gitre og! gitre. 🙂

Kommentarer

• +1 til det flotte billede leveret med ” der spiller begge sider af hegn fra en smidig kode bag fil “.
• Meget hjælpsom denne. Jeg ‘ laver en meget tung gitterbaseret app, og jeg ‘ har udelukket silverlight, xbap, og det var nede i et show ned mellem disse to.

Min erfaring:

• Skrev CakePHP-projekter i et år.
• Gennemførte et mellemstort webforms-projekt over seks måneder.
• Arbejdet med et Windows Forms-projekt i tre år.

Efter denne oplevelse, jeg prøvede at skrive en anden app ved hjælp af webformularer og blev frustreret efter at have kæmpet i ca. en dag med, hvordan webformularer forsøger at beskytte udvikleren mod den virkelighed, at de udvikler en applikation, der bruger html, javascript og css.

Jeg prøvede derefter MVC og havde mere direkte kontrol over output (og nogle erfaringer med MVC-paradigmet fra CakePHP) Jeg var i stand til at fuldføre den enkle app nøjagtigt som jeg ville have den på omkring 1/2 om dagen.

Tilgængeligheden af kraftfulde UI-rammer som jQuery i høj grad eli udråber appellen om at opgive direkte kontrol over output til fordel for ofte omfangsrige forudbyggede UI-komponenter.

Kommentarer

• @JimG – Uhh , alt, hvad der involverer en person, der indtaster poster uden interessante tilknytninger til en database, og får den person eller en anden til at læse / udskrive dem på et andet tidspunkt, kan grundlæggende stilladses ved hjælp af en MVC-ramme. Indrømmet, det er ikke ‘ t de fleste apps, men det ‘ er en hel del meget mere end du kan gøre med formularer. Jeg antager, at din -1 beviser mit punkt.
• At ‘ er 1/4 af en dag.
• Men hvis kravene beløber sig til ” Jeg har brug for en app med to roller, den ene til at optage nogle oplysninger, den anden for at se på den, og jeg ‘ t virkelig ligeglad med hvordan det ser ud. ” Så ja, at ‘ er ganske gennemførligt.
• Jeg er ked af det, men at udvikle en webforms-app til at indtaste data og se data er så enkel, at det kan gøres om få timer. oprettelse af strukturen i en MVC-app, controllere, visninger og handlinger, ville tage den samme tid, men får dig ikke til et færdigt produkt.
• @ Dementic Normalt bygger man for en simpel MVC-app modeller, stilladser derefter controllere og viser og / eller genererer stilladsede controllere / visninger. Intet virkelig tidskrævende der.

Jeg foretrækker webformularer, fordi min baggrund er Windows-udvikling.

Udviklingshastighed er et nøgleproblem, og jeg kan let videregive et problem til nogen i Indien for at ordne natten over med formularer, også hvis jeg har et hastighedsproblem på en side, en rigtig god bog om asp.net hastighed er praktisk (Rick Kiessig er manden).

webforms er for eksempel windows mennesker mvc er for webfolk

men i den moderne verden, hvor Rick har skrevet en fantastisk bog , med servere, der øges i hastighed dagligt og billige kodere i Indien, ja, webformularer har kanten

Mine 2 cent er at altid bruge ASP.NET MVC til nye projekter, hvis du har muligheden. Efter min mening er webformularer ikke en god måde at udvikle webapps på, punktum.

Jeg synes, at abstraktion af grundlæggende REST er dårlig, hele postback-modellen er dårlig, den måde, html / css gives med en tillid på GUI-editoren er dårlig, vægten af ting som guider og GUIer til opsætning af ting er dårlig, URLerne er dårlige.

Kommentarer

• kunne du forklare mere detaljeret, hvorfor du tror det?
• Jeg tror, at abstraktion væk grundlæggende REST er tilbage, hele postback-modellen er tilbage, den måde, html / css overleveres med en tillid til GUI-editoren, er dårlig , vægten af ting som guider og GUIer til at konfigurere ting er dårlig, URLerne er dårlige osv. osv.

Jeg har ikke set denne overvejelse fremsat blandt de eksisterende 15 svar på denne tråd endnu, men jeg tror det “Det er værd at overveje.

Efter min erfaring ligner Webforms mere Win Forms og WPF end MVC er. I betragtning af dette tror jeg, man kan overveje at vælge webformularer, når holdet har mest erfaring inden for den slags teknologi, eller når webformularprojektet vil levere en grænseflade til det samme datasæt som en eksisterende (eller samtidig udviklet) vindformular eller WPF-projekt. Dette gør det muligt for udviklere at krydse mellem projekter lettere, da applikationslogik kan være ret ens mellem de to.

Som andre svar har påpeget, ligner udviklingen på MVC-rammen mere webudvikling i Ruby, PHP, Python osv. End dets Microsoft-kolleger; så naturligvis kan valget af MVC påvirkes af holdets oplevelse i disse områder sammen med de faktorer, der er indsendt i andre svar.

Kommentarer

• + 1 Bestemt et rimeligt argument for webformularer. Min frygt er, at hold følger denne tankegang for at undgå at lære nye ting. MVC er fyldt med mange mønstre, som et team måske ikke kender. At lære disse typer mønstre og implementere dem fører til bedre overholdelse af SOLID-principper, hvilket betyder bedre generel vedligeholdelse. Disse gennemprøvede teknikker er også den virkelige nøgle til genbrugelighed.

Vores grund til ikke at gå til MVC for et par år siden var det en umoden teknologi fra Microsoft. I løbet af de sidste par år er vi nu på en mere moden version (4), og MS ser ud til at have fundet ud af, hvor de skal hen med dette.Vi er dog stadig tilbageholdende med at udvikle større LOB-apps ved hjælp af MVC, da de funktioner, vi ønsker at bruge i version 4, kræver en Windows 2012-server (re web-sockets via IIS8). Jeg regner med om 1 år mere vil vi acceptere mere MVC, da forhåbentlig flere tredjepartskontroller vil være tilgængelige, teknologien vil være afgjort, og vi vil have infrastrukturen til at understøtte den.

Kommentarer

• Har du noget imod at nævne nogle af disse funktioner, som du siger kræver Windows Server 2012?

Denne beslutning afhænger af dine præferencer, dine krav eller endda din viden og erfaring.

Tid til træning af læring af MVC eller tid til at få en levering. Alt dette betyder noget for at vælge den ene eller den anden fremgangsmåde.

Er det ikke, at den ene er bedre end en anden, simpelthen både aproach eller rammer har fordele og ulemper.

Personligt jeg foretrækker MVC 3, Jeg anbefaler dig at prøve at få din egen oplevelse, men jeg er nødt til at sige, at programmet i MVC er en ren, sjov, fleksibel, udvidelig, sikker og struktureret måde.

Hilsen,

Den eneste grund til, at jeg vælger WebForms i stedet for MVC, er fordi du har langt flere tredjeparts UI-kontroller til WebForms end MVC. Jeg vælger MVC, fordi jeg arbejdede for meget med WebForms, og jeg vil arbejde med noget nyt / nyt, men stadig fra MS shop 🙂

Grundlæggende forhindrer intet dig i at slukke for viewstate i WebForms og bruge ViewModels og hvis / for sløjfer i stedet for modelbinding og serversides kontrol.

Er dette WebForms eller MVC-kode:

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

Den eneste begrænsning, jeg fandt i WebForms, er, at hvis du bruger afhængighedsinjektion / inversion af Kontrol, du kan ikke have konstruktørinjektion, da WebForms-sider skal have en parameterløs konstruktør, så du skal bruge ejendomsinjektion. Er det virkelig sådan en stor ting?

ASP.NET MVC er virkelig et svar på Ruby, og den nye, trendy og (IMO) bedre måde at afkoble browseren (klienten) fra serveren så meget som muligt.

ASP.NET Webforms giver dig en masse kontrol over klienten fra serversiden med direkte adgang stort set alt. I det væsentlige er din opfattelse og controller en i det samme, hvilket giver dig en masse strøm og de fleste gange en masse rod.

ASP.NET MVC adskiller visningen og controlleren ved at fjerne den tætte kobling af en .aspx-fil og .aspx.cs-filen, der ledsager dem i webformularer.

I det væsentlige er forskellen at have din meget mere (typisk alle) behandlingen til visning data til visningsfilen og efterlader forretningslogikken og resten i controlleren, så de begge er renere efter konvention, men også med mindre adgang til hinanden end webformularer tillader.

Kommentarer

• NÅR skal webformularer foretrækkes frem for MVC? Dette besvarer ikke det originale plakatspørgsmål.
• @WeekendWarrior – Det gør det, når du vil have mere adgang til serveren til klienten, skal du vælge webformularer. Hvis du vil have mere afkobling af klienten / serveren i din kode, skal du vælge MVC. I slutningen af dagen gør de begge nøjagtigt den samme ting. Omdiriger filtre gør det samme som MVC-webadresserne, og du kan flytte webforms-koden bag til et separat mellemliggende niveau for at afkoble det mere. weblogs.asp.net/scottgu/archive/2010/01/24/…
• Med hensyn til dit tredje punkt ender den forretningslogik i .aspx.cs-filen – jeg tror, det er udvikleres skyld. Det ‘ er ikke / formodes / at være der. I webformularer er .aspx ” visning “, .aspx.cs er ” controller ” ækvivalent, beregnet til at behandle den kode, der kun direkte vedrører brugergrænsefladen ved at afstemme et forretningslag eller grovkornet forretningsfacadelag. Det faktum, at folk lægger forretningslogik i .aspx.cs, er bare dårlig programmering. De kunne også sætte forretningslogik lige i visningen i MVC! MVC tvinger ikke ‘ til adskillelse af disse ting.
• I det væsentlige har han mere ret end andre svar, der er sendt her. ASP.net er den grundlæggende idé bag en modulær webteknologifamilie som skabt af Microsoft. ASP.net MVC-modul kan være en tidsmæssig hype, men det er bestemt ikke det sidste, det hele starter med ASP.net, så hvornår skal man vælge ASP.net, hvis du ikke tror, at MVC ikke er din ting, måske din mere til noget ellers OWIN eller …, noget mere avanceret, eller lavet din egen ramme for dine opgaver. Du har muligvis ikke engang brug for ASP.MVC og spring den over og gå Owin eller Katana, men indtil din der brug asp.net

Efter min mening er de relaterede nok og har nogenlunde de samme muligheder, som det skulle komme ned til præference.

En stor WebForms-udvikler kan producere et produkt, der er lige så kraftigt som en stor MVC-udvikler. Men den store WebForms-udvikler, der forsøger at tvinge sig selv til at vedtage MVC, kommer til at komme kort. Det samme gælder for en stor MVC-udvikler, der giver WebForms et skud.

De er ikke helt separate enheder, og så længe Microsoft fortsætter med at støtte begge dele, tror jeg, du vil fortsætte med at se en blandet gruppe af ekstraordinære udviklere for hver.

Dette handler om personligt valg, forudsat at vi alle er dygtige med den teknologi, vi bruger. Jeg har brugt WebForms designmetoden i mange år, og jeg må sige, at den eneste ulempe er, at på grund af den forenklede tilgang tager mange mennesker ikke deres tid til at finde den store kapacitet.

Jeg brugte for nylig MVC til at gennemføre et projekt, og selvom jeg meget godt kan lide designtilgangen til applikationsudvikling (som giver dig mere kontrol, rene webadresser, SOC osv.), er der virkelig ikke meget det giver , at WebForms ikke kan t. Faktisk har fremkomsten af jQuery og dets arbejde med WebForms (såvel som MVC) gjort disse argumenter mindre af et problem. Og når folk taler om adskillelse af bekymringer som en fordel MVC har i forhold til MVP, spørger jeg dem, hvor meget de kender til objektorienteret programmering, og hvor meget de bruger princippet om abstraktion og polymorfisme.

Jeg er i øjeblikket fortrolig med at bruge begge teknologier, og jeg vælger og vælger ud fra situationen. til dig, men sandheden er, at ikke alle tager sig tid til at lære dybtgående, hvad en bestemt teknologi er i stand til.

Kommentarer

• Ditto on webformularernes store kapacitet. De fleste mennesker ser træningshjulene til webformularer og sammenligner dette med MVC.
• Der er ringe mening at lære en abstraktion oven på HTML og Javascript i dag og i dag (selv i 2013). Det ‘ vil ikke hjælpe dig med dine fremtidige muligheder. HTML og Javas cript er bare fint, som det er. At bekæmpe det er en tabende kamp.

Når jeg står over for et programmeringsproblem, ser jeg ofte på nettet for svar. Webforms har masser af oplysninger / komponenter om at gøre næsten alt. I MVC på grund af færre kilder online og de lag af abstraktioner, der er nødvendige for at få noget til at fungere, har der været en grænse for ting, som jeg engang kunne gøre. MVC-total dræber min produktivitet som udvikler, mens det med Webforms ikke er tilfældet. Så for nu holder jeg mig til webformularer, indtil MVC er modnet nok til at erstatte det.

Nå, WebForms har flere læringsressourcer til rådighed (simpelthen på grund af det faktum, at det er ældre), og det er derfor mere sandsynligt, at nye programmører, der ikke er “t” i know ” oplysninger om denne ældre teknologi i modsætning til de nyere ting som MVC.

Senior / erfarne programmører er ældre og vil være mere dygtige i den ældre teknologi på grund af det faktum, at de har programmeret i den længere end de har i den nyere.

Medmindre du kan bruge pengene og kræfter på at få dine fyre så dygtige til MVC som de er i WebForms-applikationer, vil du utvivlsomt forsøge at holde op med at opgradere til den nye platform så længe som muligt.

Så det præsenterer flere logistiske problemer: Gør fordelene ved MVC opvejer omkostningerne i form af mindre kvalitet og implementeringstid? Hvis jeg har et websted skrevet udelukkende i WebForms, ville det være umagen værd at integrere MVC i det?

Som anført af en tidligere kommentator forhindrer MVC dig også i at opnå det samme niveau af interface med controlleren, som du ville være i stand til med WebForms. Mens jeg er alt for “Holde brugeren i at fylde ting op / lære” -siden af tingene, kan det stadig være urimeligt besværligt for hold at implementere / implementere et program, der fanatisk holder fast i det paradigme for alt, hvad de skriver.

Jeg tror, at afstanden mellem disse to teknologier ikke er så bred som den var.

• Webformularer kan bruge den routing-motor, som MVC bruger (eller noget meget lignende).
• Scriptmanageren kan kombinere scripts, indlæse fra et CDN og endda forsinke indlæsningen af scripts.

For at svare direkte på dit spørgsmål synes jeg det kommer til præference og / eller hvad projektet er. De tager begge en væsentlig forskellig tilgang til udvikling. Personligt har jeg arbejdet med at bevæge mig mod MVC, men jeg nyder stadig at arbejde med Webforms. Jeg synes, at svaret på, om du skal bruge MVC eller Webforms, er for dig at beslutte gennem at opleve begge teknologier.

Kommentarer

• Webformularer og MVC anbefaler en radikalt anden webudviklingsindstilling som standard, dette er vigtigt , få udviklere afviger fra ” standard “. Begge kan dog bruges til at opnå det samme.