Wanneer ASP.NET WebForms verkiezen boven MVC

Webformulieren versus MVC lijken momenteel een hot topic te zijn. Iedereen die ik ken, prijst MVC als het volgende geweldige ding. Op basis van mijn kleine opmerkingen, lijkt het oké, maar nee, ik denk niet dat dit het einde van webformulieren zal zijn.

Mijn redenering en de redenering waarom webformulieren zouden worden gekozen boven MVC, is meer te maken hebben met een zakelijk perspectief dan met wat het ene beter is dan het andere.

Tijd / geld zijn de belangrijkste redenen waarom webformulieren zouden worden verkozen boven MVC.

Als de meeste van uw team kent webformulieren, en je hebt geen tijd om ze op de hoogte te brengen van MVC, de code die zal worden geproduceerd, is misschien niet van kwaliteit. De basis van MVC leren en vervolgens naar binnen springen en die complexe pagina doen die je moet doen, zijn heel verschillende dingen. De leercurve is hoog, dus u moet daar rekening mee houden in uw budget.

Als u een grote website heeft die volledig in webformulieren is geschreven, bent u wellicht eerder geneigd om nieuwe paginas in webformulieren te maken, zodat u dat niet doet ” Er zijn twee heel verschillende soorten paginas op uw site.

Ik zeg niet dat het hier een alles of niets benadering is, maar het maakt uw code moeilijker te onderhouden als er een splitsing is van beide , vooral als niet iedereen in het team bekend is met MVC.

Mijn bedrijf heeft onlangs drie testpaginas met MVC gemaakt. We zijn gaan zitten en hebben ze ontworpen. Een probleem dat we tegenkwamen, is dat de meeste van onze schermen de View en Edit functionaliteit op dezelfde pagina. We hadden uiteindelijk meer dan één formulier nodig op de pagina. Geen biggy, behalve dan zouden we onze masterpage niet gebruiken. We moesten dat vernieuwen, zodat zowel de webformulierpaginas als de MVC-paginas dezelfde masterpagina konden gebruiken voor een gemeenschappelijke look en feel. Nu hebben we een extra nestlaag.

We moesten een geheel nieuwe mappenstructuur voor deze paginas maken, zodat deze de juiste MVC-scheiding volgde.

Ik vond dat er te veel bestanden waren voor 3 paginas, maar dat is mijn persoonlijke mening.

Naar mijn mening zou je webformulieren verkiezen boven MVC als je geen tijd / geld hebt om te investeren in het updaten van je site om MVC te gebruiken. Als je dit op een half arse manier aanpakt, het zal niet beter zijn dan de webformulieren die u nu heeft. Erger nog, u zou deze technologie zelfs kunnen instellen voor een mislukking in uw bedrijf als het in de war is, aangezien het hogere management het misschien als iets minder dan wat ze weten kan beschouwen.

Opmerkingen

• Dit is een goed antwoord. Ik heb je +1 gegeven omdat je persoonlijke ervaringen worden gewaardeerd. Maar dit is een mislukking vanwege een gebrek aan ervaring / vaardigheidsset van de ontwikkelaars, wat ik heb gevraagd te vermijden . Ik ben er niet van overtuigd dat Microsoft ervoor zou kiezen om een technologie niet als verouderd te markeren, simpelweg uit angst voor de leercurve voor MVC. Dit kan het geval zijn, maar ik ‘ ben nog niet overtuigd.
• @ P.Brian.Mackey – Ik heb niet ‘ gezegd dat de ontwikkeling van formulieren sneller gaat dan MVC. Je vroeg om dat argument weg te laten. Tijd en geld ruzie maken om uw personeel op te leiden, is een ander argument. MS heeft ‘ geen webformulieren als verouderd bestempeld om één belangrijke reden: Enterprise-klanten hebben jarenlang webclients ontwikkeld in webformulieren en hebben gewonnen ‘ kijk er niet goed naar uit om tijd en geld te investeren om te updaten.
• @Raynos – Als iedereen in het team bedreven was in MVC, en uw bedrijf was een nieuw project aan het starten, dan is de enige reden dat ik iemand voor webformulieren kon zien kiezen, een persoonlijke keuze.
• Ik ken beide technologieën door en door. Al mijn webprojecten doe ik met mvc en werk bij een bedrijf waar ik de vrije hand heb om te doen wat de beste aanpak is. Ik koos altijd voor MVC.
• Ik begon met webformulieren en toen ik eenmaal MVC ontdekte, schakelde ik daarop over. Ik weet niet ‘ hoe iemand webformulieren zou kunnen verdedigen. Paginalevenscyclus en één formulier voor de hele pagina? Maak je een grapje? Yahoo sitebuilder was waarschijnlijk de beoogde klant ervoor, maar zelfs zij wilden die rommel niet ‘.

Ik heb 3 jaar lang ASP .Net WebForms-applicaties ontwikkeld, en na een dag een MVC-tutorial te hebben gedaan, was ik verkocht. MVC is bijna ALTIJD de betere oplossing. Waarom?

• De levenscyclus van een pagina is eenvoudiger en efficiënter
• Er bestaat niet zoiets als besturingselementen behalve html-besturingselementen. U hoeft uw uitvoer niet te debuggen om te zien wat ASP .Net genereert.
• ViewModels geven u een enorme kracht en elimineren de noodzaak om handmatige controlebinding uit te voeren en het elimineert veel fouten met betrekking tot binding.
• Je kunt meerdere formulieren op een pagina hebben. Dit was een ernstige beperking van WebForms.
• Het web is staatloos en MVC komt beter overeen met de architectuur van het web. Webforms introduceert de status en de bugs je hebt ermee te maken door de ViewState te introduceren. De ViewState is automatisch en werkt op de achtergrond, dus het gedraagt zich niet altijd zoals jij dat wilt.
• Webapplicaties moeten tegenwoordig met ajax werken. Het is niet acceptabel dat de volledige pagina nog wordt geladen. MVC maakt ajax zo veel beter, gemakkelijker en efficiënter met JQuery.
• Omdat je meerdere formulieren op een pagina kunt hebben, en omdat de architectuur gedreven door oproepen naar URLs, kunt u funky dingen doen, zoals ajax een ander formulier laden, zoals een bewerkingsformulier in uw huidige pagina met JQuery. Zodra u zich realiseert wat u hiermee kunt doen, kunt u gemakkelijk geweldige dingen doen.
• ASP .Net WebForms is niet alleen een abstractie van html, het is ook een buitengewoon complexe. Soms krijg je een rare bug en worstelt er veel langer mee dan nodig is. In veel gevallen kon je echt zien wat het fout deed maar je kunt er niets aan doen. Uiteindelijk doe je rare oplossingen.
• WebForms is geen goede technologie voor ontwerpers. Ontwerpers werken vaak graag rechtstreeks met html. In MVC is het een weergave, in WebForms het is een halve dag werk.
• Aangezien het webplatform snel evolueert, zullen WebForms het niet bijhouden. Het is niet op de hoogte van nieuwe tags of functies van HTML5, zal het nog steeds hetzelfde weergeven, tenzij je (vaak) dure besturingselementen van derden krijgt of wacht tot Microsoft een update uitgeeft.
• Controles in WebForms beperken u op zoveel manieren. In MVC kun je gewoon een JQuery-bibliotheek pakken en deze in je sjablonen integreren.

Ik weet dat sommige van de bovenstaande problemen tot op zekere hoogte zijn aangepakt naarmate WebForms evolueert, maar dat was mijn oorspronkelijke ervaring. Al met al zou ik het buitengewoon moeilijk vinden om een businesscase voor WebForms te vinden, tenzij een project er al gebruik van maakt.

Opmerkingen

• +1 voor wijzen op meerdere vormen. Bovendien is het feit dat de HTML-webformulieren genereren meestal niet erg SEO-vriendelijk (zoals in: grote stukken viewstate bovenaan de pagina).
• Ik moet het 100% eens zijn met dit antwoord. Aan het eind van de dag zorgt WebForms ervoor dat dingen aan de clientzijde (html / browser) zo veel moeilijker worden. Je moet letterlijk tegen het raamwerk vechten om iets gedaan te krijgen. Een aspx-pagina krijgt zoveel meer code vanwege servercontroles dan een cshtml-pagina doorgaans doet. @ šljaker Als je ViewState uitschakelt en serverbediening vermijdt, ‘ heb je op dat moment veel van WebForms verlaten. Ik zie dat argument niet als bijzonder overtuigend ‘.
• Je kunt eenvoudige html-besturingselementen in WebForms hebben, niemand dwingt je om Server-besturingselementen te gebruiken. U kunt een volledig staatloos webformulier hebben, niemand dwingt u om ViewState te gebruiken. U kunt volledige ajax en jQuery gebruiken in webformulieren, niemand beperkt u in het gebruik van jQuery. U kunt URL-routering implementeren, niemand dwingt u om een statische basis-URL voor bestanden te gebruiken. Het handmatig tekenen van een pagina met CSS kost net zoveel tijd als MVC nodig heeft. U kunt een HTML-pagina rechtstreeks op Webform ontwerpen.
• @mjb: als u geen ‘ gebruikmaakt van serverbesturing, ViewState enzovoort, waarom zou u dan WebForms gebruiken als MVC is dichter bij wat u ‘ doet? Het ‘ is als het besturen van een tractor naar het werk, maar niet offroad rijden of de schop / schoffel of stabilisatorstangen gebruiken. Waarom gebruik je dan niet gewoon een auto?
• @Tjaart Het is niet helemaal juist dat je niet meerdere formulieren op de ASPNET-pagina kunt hebben.Je zou zoveel formulieren kunnen hebben als je wilt op de ASPNET-pagina, maar je zou maar één serverformulier kunnen hebben – formulier met runat = ” server ” attribuut.

Ik heb een e-mail gestuurd naar Scott Guthrie , een MVC-expert bij Microsoft. En waarschijnlijk de meest gekwalificeerde man om deze vraag te beantwoorden. Hij was zo vriendelijk om te antwoorden:

“Verschillende klanten zoeken naar verschillende programmeerbenaderingen, en veel houden van WebForms en vinden het geweldig. Anderen houden van MVC en vind het geweldig. Daarom investeren we in beide. “

Dus, voor mij zegt dit dat het geen technisch probleem is. Het is meer een “zachte kwestie”, als je wilt. Een van persoonlijke voorkeur. Dit is in overeenstemming met wat verschillende van jullie hebben gezegd.

Bedankt voor alle antwoorden.

Reacties

• Scott Guthrie heeft uitgevonden het MVC-framework voor ASP.NET tijdens een vlucht terug van Londen naar Seattle in 2006/7. Nu ik erover nadenk, heeft hij ook .NET uitgevonden ( en.wikipedia.org/wiki/Scott_Guthrie ). Hem een ” expert ” noemen is een enorm understatement 😉
• Dat ‘ is een mooi politiek antwoord van Scott Guthrie. Als hij zelf zijn eigen webapplicatie zou investeren, zou je ‘ een MVC-project zien en voor alles dat niet ‘ kon worden gedaan in MVC, Silverlight zou de fallback zijn. Gebruik ‘ dit niet als een negatieve reactie op WebForms, ik denk dat WebForms geweldig zijn voor kleinere interne applicaties die kunnen profiteren van componenten van derden, zoals die gemaakt door Telerik. Ik ‘ ben blij dat Microsoft vooruitgang boekt met beide technologieën.
• ” Scott Guthrie heeft het MVC-framework voor ASP uitgevonden .NET tijdens een vlucht ” Ik denk dat dit MVC echt bagatelliseert. Ik ‘ ken Scott Guthrie niet, maar ik ‘ durf te wedden dat hij had nagedacht over hoe MVC zou kunnen worden geïmplementeerd in ASP.NET een tijdje, en hebben die lange vlucht gebruikt om een kaal prototype te implementeren als een proof of concept.
• ” Daarom investeren we in beide. ” En wanneer we zien dat webformulieren beginnen af te nemen, zullen we deze genadeloos laten vallen omdat investeren in een uiteindelijk dood product niet in ons beste zakelijke belang is.
• Tot het wordt niet meer op scholen onderwezen, jarenlang zal het altijd toepasbaar zijn in de zakenwereld. Hogescholen en middelbare scholen blijven introductiecursussen en cursussen voor gevorderden aanbieden op vb.net. Het gaat nergens heen !!!

Dit is een oude vraag met veel antwoorden, maar geen had het antwoord waarvan ik had verwacht dat het in de lijst zou worden vermeld.

Het korte antwoord is:

• Gebruik ASP.NET MVC als je van plan bent om een webtoepassing op de juiste manier te bouwen met moderne programmering conventies en industrie omarmden patronen voor het ASP.NET-platform. Aan de andere kant wordt er van je verwacht dat je weet hoe HTML en bronnen aan de clientzijde (Javascript, CSS) werken, en dat je de MVC-programmeermentaliteit opvoert, die een steile leercurve heeft maar een plotseling einde bereikt als je eenmaal begrepen hebt.
• Gebruik ASP.NET-webformulieren als u “een GUI -centrisch, RAD (Rapid Application Development) , drag-and-drop-benadering voor het heel snel prototypen van iets, dwz het gedrag van drukknoppen / datanetwerken bedraad binnen 15 minuten, en de oplossing is niet bedoeld als iets dat wordt ondersteund door ontwikkelaars. Of Gebruik ASP.NET Web Forms als u een achtergrond heeft in GUI of Windows Forms-ontwikkeling en u wilt uw kennis op het web.

Maar om dit goed te kunnen bekijken, moet u de geschiedenis van elk begrijpen.

ASP.NET Web Forms was het antwoord van Microsoft op degenen die dynamische webapplicaties hadden gebouwd met Visual Basic 6 Ac tiveX-besturingselementen, VB6 DLLs op de server en ASP Classic. Destijds was webontwikkeling met behulp van deze Microsoft-tools een echte puinhoop. Samen met het volledige .NET Framework, dat de output was van Microsoft, dat in wezen terugging naar de tekentafel over hoe productief zakelijk programmeren op de Windows-stack te doen, was ASP.NET Web Forms in zijn tijd geweldig en mooi.

De hele aanpak was om ontwikkelaars het beste van twee werelden te geven van iets dat erg lijkt op de ontwikkeling van Windows-applicaties, maar met de kracht van internetservices.Het idee was dat, net als bij een VB6 / WinForms “Form” (een venster), ook een webpagina een formulier is (net als een venster, zie) , en op dat formulier kon je labels, tekstvakken, gegevensrasters, knoppen en andere dingen slepen en neerzetten waar VB / WinForms GUI-ontwikkelaars aan gewend waren.

Om een knop iets te laten doen, dubbelklikt u er na het slepen en neerzetten op in de ontwerper en u bent in de code-editor en vertel het formulier wat te doen als die “klik “event happening. Dit was precies hoe Windows GUI-ontwikkelaars software hebben gemaakt met behulp van GUI -tooling van VB6 en concurrerende tools, behalve dat de code nu op de server wordt uitgevoerd! Wauw!

Dit was technologie uit 2002. Verbazingwekkend en mooi in zijn tijd als antwoord op internet -ingeschakeld GUI -oplossingen voor RAD -ontwikkeling , het gaf een gevoel van macht naar een rommelige wereld van softwareontwikkelaars die zakelijke doelstellingen hadden die ze moesten bereiken.

Helaas benadrukt dit programmeermodel zozeer de metafoor van Windows GUI-programmering dat het de last van de noodzakelijke implementatiedetails met zich meebrengt , alle belastende bagage, neg essentieel om de levenscycli van de gebeurtenis te accommoderen en het wegstoppen van de lelijke details van de eenvoudige HTML en het script die deze componenten en bedieningselementen met slepen en neerzetten zouden produceren. En aan het eind van de dag moesten ontwikkelaars die echte toepassingen ondersteunden onvermijdelijk diep in deze componenten graven of hun eigen componenten schrijven, en bijgevolg zouden ze gevechten voeren met deze infrastructuur, gevechten die stapels op stapels cruft, getrokken haar en tranen.

Maak een back-up. Was je handen. Laten we het bedrijfsprobleem nog eens bekijken. Wat zijn onze bedrijfsdoelstellingen?

We moeten webapplicaties bouwen en beheren. Onze beperkingen zijn dat we het World Wide Web hebben, die staat op HTTP, HTML, Javascript en CSS, en op de server hebben we bedrijfsregels, databases en een klein handvol geweldige programmeertalen (bijv. C #). Hebben we deze Windows GUI-metafoor echt nodig om onze ontwikkelingsmethodologie te sturen? Waarom kunnen we ons niet alleen concentreren op de applicatieproblemen en de GUI-metaforen verwijderen?

Dit is waar ASP.NET MVC om de hoek komt kijken. Het begon door een opstand van ontwikkelaars die zichzelf “Alt.Net” noemden en die terug wilden naar de juiste en zuivere principes van softwareontwikkeling. Geen gedoe meer, concentreer u gewoon op bedrijfsdoelstellingen en best practices voor software.

Waar dit in dit geval echt naar vertaalt is:

1. Scheiding van zorgen . Een gegevenscomponent hoeft bijvoorbeeld niet te weten hoe de gegevens worden weergegeven, noch mag de weergave van opmaak worden belast met configuratiedetails voor databaseverbindingen, en op deze manier kan een ontwikkelaar zich concentreren op zijn aandachtsgebied bij het bewerken en testcode.
2. Blootstelling en volledige ondersteuning voor blootstelling aan de kern van HTML en gerelateerde bronnen . In Web Forms is HTML weggestopt, ontwikkelaars worden ontmoedigd om zich daar druk over te maken. In ASP.NET MVC worden ontwikkelaars eerder aangemoedigd om die details te beheren, in feite is het een noodzaak. Het voordeel hiervan is dat de ontwikkelaar opnieuw kan leren de schone semantiek van HTML, CSS en script te waarderen en er met mee te werken in plaats van ertegen.
3. Testbaarheid van bedrijfsobjecten . Controllers en modellen zijn veel beter geschikt voor programmatic unit testing, zodat implementaties gevalideerd kunnen worden om aan de bedrijfsdoelstellingen te voldoen, en veranderingen kunnen worden geverifieerd dat ze niet kapot gaan. Met webformulieren was het moeilijk om te testen omdat componenten niet ontworpen waren om afzonderlijk te worden getest en de volledige ontwikkelingsoutput draaide om paginavormen en de levenscycli van hun gebeurtenissen, waarbij de modderige bedrijfslogica en presentatielogica diep met elkaar verweven waren. / li>

Merk op dat HTML al een opmaaktaal op zeer hoog niveau is, net als Javascript een programmeertaal op hoog niveau. Het hele verhaal zou anders zijn geweest als we te maken hadden met Assembly-taal en C.

Uitbreiding op # 2, dan is een ander doel van ASP.NET MVC om ontwikkelaars in staat te stellen de front-end details van het “bekijk” -gedeelte van hun oplossingen en profiteer van de rijke basis die de rest van de branche heeft gebouwd op het front-end clientplatform.

U zult merken dat ASP.NET MVC-ontwikkelaars zich thuis voelen door rijke Javascript-bibliotheken en client-side template-technieken te gebruiken zonder te vechten met de server-side architectuur. Bij ASP was dit oorspronkelijk niet het geval.NET Web Forms, omdat Web Forms helemaal niet wil dat je naar de HTML of het script kijkt, behalve als het echt moet , in welk geval pas op, het is niet voor bangeriken .

Opmerkingen

• Dit is een goed antwoord, maar # 1 en # 2 zijn verkeerd (WF vereist geen component om te weten waar de gegevens vandaan komt, het is een optie en je hebt altijd HTML aan je ASPX-bestanden toegevoegd om de asp-tags die je aan het renderen bent te ondersteunen. Je hebt nooit diep hoeven graven en de controles moeten bestrijden, tenzij je probeerde toegang te krijgen tot een ASP-functie die niet bedoeld was voor ontwikkelaars interactie. De grote punten zijn testbaarheid en ontwerppatroon.)

Ik ben een complete en totale bekeerling naar ASP.NET MVC en heb niet achterom gekeken, dat zei dat ik nog steeds verschillende zeer grote WebForms-apps moet onderhouden. Hier is mijn mening:

WebForms
Gebruik deze als je een serieus zwaar leven hebt ting te maken met roosters. De rasterknoppen zijn echt heel prettig als je een eenvoudige dataset hebt die mooi in een tabelformaat past en je gebruikers een eenvoudige manier wilt bieden om records bij te werken. Ja, ik weet dat MVC 4 een echt hip Ajax-lijst-achtig ding heeft dat je kunt gebruiken en dat geweldig werkt, maar in onze branche moeten we gisteren vaak iets laten draaien en goede ouderwetse grids werken geweldig en gebruikers zijn daar blij mee. in staat om met vreugde over een raster te tikken. Voor mij “is dat echt het beste aan WebForms voor mij; maar, zoals Ryan opmerkte, kan WebForms een grote puinhoop zijn omdat je beide kanten speelt van het hek uit een handig code-achter-bestand. Het kan tegelijkertijd een roos en een doorn zijn om al je controller-achtige dingen vermengd te houden met je mening (en).

MVC
Gebruik dit wanneer u echt uw eigen wilt rollen en u de mogelijkheid heeft om een applicatie helemaal opnieuw te starten. Het hebben van een duidelijk gedefinieerde MVC-applicatie is wat meer werk om mee te beginnen, maar de voordelen op het gebied van onderhoud zijn groter dan de initiële installatiekosten. Als je interessante Ajax-interacties wilt doen, je model liever met code schrijft, zoals schone urls en routes, en de volledige stroom van je app wilt beheersen, dan is dit zeker de juiste keuze. Het is even wennen maar ik denk dat het in eerste instantie de betere optie is voor greenfield-apps.

Tot slot komt het voor mij neer op grids en! grids. 🙂

Reacties

• +1 voor de mooie foto geleverd met ” beide kanten van de afschermen van een handig code-achter-bestand “.
• Zeer nuttig deze. Ik ‘ m bezig met een zeer zware op rasters gebaseerde app en ik ‘ heb silverlight, xbap uitgesloten en het was een show down tussen deze twee.

Mijn ervaring:

• CakePHP-projecten geschreven gedurende een jaar.
• Voltooide een middelgroot Webforms-project gedurende zes maanden.
• Werkte drie jaar aan een Windows Forms-project.

Na die ervaring probeerde ik een andere app te schrijven met behulp van webformulieren, en raakte gefrustreerd nadat ik ongeveer een dag had geworsteld met hoe webformulieren de ontwikkelaar proberen te beschermen tegen de realiteit dat ze een applicatie ontwikkelen die html, javascript en css gebruikt.

Ik heb toen MVC uitgeprobeerd, en met meer directe controle over de output (en enige ervaring met het MVC-paradigma van CakePHP) kon ik die eenvoudige app in ongeveer een halve dag voltooien zoals ik hem wilde hebben.

De beschikbaarheid van krachtige UI-frameworks zoals jQuery is erg eli vermindert de aantrekkingskracht van het opgeven van directe controle over de output ten gunste van het gebruik van vaak omvangrijke vooraf gebouwde UI-componenten.

Reacties

• @JimG – Uhh , alles waarbij een persoon records invoert zonder interessante associaties in een database, en die persoon of iemand anders ze op een ander punt laat lezen / afdrukken, kan in feite worden ondersteund met behulp van een MVC-framework. Toegegeven, dat is niet ‘ t de meeste apps, maar het is ‘ veel meer dan je kunt doen met Formulieren. Ik denk dat je -1 mijn punt bewijst.
• Dat ‘ 1/4 van een dag is.
• Maar als de vereisten neerkomen op ” Ik heb een app nodig met twee rollen, de ene om wat informatie vast te leggen, de andere om ernaar te kijken, en ik heb niet echt ‘ het kan me schelen hoe het eruit ziet. ” Dan, ja, dat ‘ is best te doen.
• Het spijt me, maar het ontwikkelen van een webformulieren-app om gegevens in te voeren en gegevens te bekijken is zo eenvoudig dat het binnen een paar uur kan worden gedaan. het creëren van de structuur van een MVC-app, controllers, weergaven en acties, zou evenveel tijd kosten, maar het zal je niet naar een afgewerkt product brengen.
• @Dementic Gewoonlijk bouwt men voor een eenvoudige MVC-app modellen, steiger dan controllers en views en / of genereert scaffolded controllers / views. Niets echt tijdrovend daar.

Ik geef de voorkeur aan webformulieren omdat mijn achtergrond Windows-ontwikkeling is.

Snelheid van ontwikkeling is een belangrijk probleem, en ik kan gemakkelijk een probleem doorgeven aan iemand in India om het s nachts met formulieren op te lossen, en als ik een snelheidsprobleem op een pagina heb, een heel goed boek over asp.net snelheid is handig (Rick Kiessig is de man).

webformulieren zijn voor ex windows-mensen mvc is voor internetmensen

maar in de moderne wereld, waar Rick een geweldig boek heeft geschreven , met servers die dagelijks in snelheid toenemen en goedkope codeerders in India, nou, webformulieren hebben een voorsprong

Mijn 2 cent is om altijd ASP.NET MVC te gebruiken voor nieuwe projecten als je de mogelijkheid hebt. Naar mijn mening zijn webformulieren geen goede manier om web-apps te ontwikkelen, punt.

Ik denk dat het wegnemen van basis REST slecht is, het hele postback-model is slecht, de manier waarop html / css wordt aangeleverd met vertrouwen op de GUI-editor is slecht, de nadruk op dingen zoals wizards en GUIs om dingen op te zetten is slecht, de URLs zijn slecht.

Reacties

• zou je in meer details kunnen uitleggen waarom je dat denkt?
• ik denk dat het wegnemen van basis REST terug is, het hele postback-model is terug, de manier waarop html / css wordt overhandigd met een beroep op de GUI-editor is slecht , de nadruk op zaken als wizards en GUIs om dingen op te zetten is slecht, de URLs zijn slecht, enz.

Ik heb alle antwoorden gelezen en denk dat mijn persoonlijke ervaring iets zou toevoegen aan de bovenstaande antwoorden.

3-4 jaar geleden ontwikkelde ik 2-3 websiteprojecten met behulp van webformulieren. Rond die tijd was MVC er niet of had ik er niets van gehoord. De ontwikkeling was natuurlijk (ik kwam uit de ontwikkeling van Win-Forms zonder eerdere ervaring met webontwikkeling) snel voor mij, omdat ik geen HTML in details hoefde te leren en webcontroles veel hielpen (heel veel, het maakte het leven gemakkelijker) .

Nu, na al die tijd, werkte ik tot voor kort niet aan een webproject en bouwde ik alleen een Windows-applicatie met WPF.

Enkele dagen geleden had ik een idee voor een website en dacht eraan om het te ontwikkelen: dit keer in MVC (aangezien er overal over wordt gesproken, behalve dat ik ook moest leren, dus ik koos voor MVC) Het project bevindt zich nog in de ontwikkelingsfase, aangezien ik nog steeds samen aan het leren en bouwen ben. / p>

Dus de belangrijkste verschillen die ik vind tussen de twee zijn de volgende: –

• Voor iemand die uit Windows-ontwikkeling komt, zullen webformulieren altijd gunstig zijn. .net leercurve voor een Windows-ontwikkelaar is een beetje steil

• Voor iemand die afkomstig is van webontwikkeling in een andere technologie, zal MVC de voorkeur genieten omdat het de spot drijft De laatste van allemaal.

• Ontwikkeling is gemakkelijker en schoner in MVC als u beschikt over een goede kennis van HTML en CSS.

• De implementatie is nog steeds een probleem. In webformulieren hoefde men alleen maar te kopiëren en plakken. Maar dit vereist een aantal dingen die gedaan moeten worden.

Kortom, ze zullen allebei een tijdje hier blijven.

Ik heb deze overweging nog niet naar voren zien komen bij de bestaande 15 antwoorden op deze thread, maar ik denk het Het is het overwegen waard.

Vanuit mijn ervaring lijkt Web Forms meer op Win Forms en WPF dan op MVC. Gezien dit, denk ik dat men zou kunnen overwegen om voor Web Forms te kiezen wanneer het team de meeste ervaring heeft met dat soort technologie, of wanneer het Web Forms-project een interface levert met dezelfde dataset als een bestaande (of gelijktijdig ontwikkelde) Win Forms of WPF-project. Hierdoor kunnen ontwikkelaars gemakkelijker tussen projecten oversteken, aangezien de applicatielogica tussen de twee behoorlijk op elkaar kan lijken.

Zoals andere antwoorden hebben aangegeven, lijkt ontwikkeling op het MVC-framework meer op webontwikkeling in Ruby, PHP, Python enz. Dan zijn Microsoft-tegenhangers; dus natuurlijk kan de keuze van MVC worden beïnvloed door de ervaring van het team op die gebieden, samen met de factoren die in andere antwoorden worden ingediend.

Opmerkingen

• + 1 Zeker een redelijk argument voor webformulieren. Ik ben bang dat teams deze mentaliteit volgen om te voorkomen dat ze nieuwe dingen leren. MVC is gevuld met veel patronen die misschien onbekend zijn voor een team. Het leren van dit soort patronen en het implementeren ervan leidt tot een betere naleving van SOLID-principes, wat zich vertaalt in een betere algehele onderhoudbaarheid. Deze bewezen technieken zijn ook de echte sleutel tot hergebruik.

Onze reden om niet te gaan aan MVC een paar jaar geleden was het een onvolwassen technologie van Microsoft. De afgelopen jaren zitten we nu op een meer volwassen versie (4) en MS lijkt te hebben uitgezocht waar ze hiermee naartoe gaan.We zijn echter nog steeds terughoudend bij het ontwikkelen van grote LOB-apps met MVC, omdat de functies die we in versie 4 willen gebruiken een Windows 2012-server vereisen (opnieuw websockets via IIS8). Ik denk dat we over nog 1 jaar MVC meer zullen accepteren, omdat hopelijk meer controles van derden beschikbaar zullen zijn, de technologie zal zijn opgelost en we de infrastructuur zullen hebben om het te ondersteunen.

Opmerkingen

• Zou u het erg vinden om een aantal van deze functies op te sommen waarvan u zegt dat Windows Server 2012 vereist is?

Deze beslissing hangt af van uw voorkeuren, uw vereisten of zelfs uw kennis en ervaring.

De tijd voor het leren van MVC-training of tijd om een levering te krijgen. Al deze dingen zijn van belang om de ene of de andere aanpak te kiezen.

Is dat niet de ene beter dan de andere, dan hebben beide benaderingen of frameworks gewoon voor- en nadelen.

Persoonlijk ben ik voorstander van MVC 3, Ik raad je aan om te proberen en je eigen ervaring op te doen, maar ik moet zeggen dat programma in MVC een schone, leuke, flexibele, uitbreidbare, veilige en gestructureerde manier is.

Met vriendelijke groet,

De enige reden waarom ik zou kiezen voor WebForms in plaats van MVC is omdat je veel meer UI-controls van derden hebt voor WebForms dan MVC. Ik heb voor MVC gekozen omdat ik te veel met WebForms heb gewerkt en ik wil met iets fris / nieuws werken, maar nog steeds van MS shop 🙂

Kortom, niets belet je om de viewstate in WebForms uit te schakelen en ViewModels te gebruiken en if / for loops in plaats van model binding en server side controls.

Is dit WebForms- of MVC-code:

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

De enige beperking die ik in WebForms vond, is dat als je Dependency Injection / Inversion of Controle, je kunt “geen constructor-injectie hebben, aangezien WebForms-paginas een parameterloze constructor moeten hebben, dus je moet property-injectie gebruiken. Is dit echt zo belangrijk?

ASP.NET MVC is echt een antwoord op Ruby, en de nieuwe, trendy en (IMO) betere manier om de browser (client) zoveel mogelijk los te koppelen van de server.

ASP.NET Webforms geeft u veel controle over de client vanaf de server, met directe toegang voor vrijwel alles. In wezen zijn uw weergave en controller één in hetzelfde, wat u veel kracht en meestal veel rommel geeft.

ASP.NET MVC scheidt de weergave en de controller door de nauwe koppeling van een .aspx-bestand en het .aspx.cs-bestand dat hen vergezelt in webformulieren.

In wezen is het verschil dat uw veel meer (meestal alle) verwerking om weer te geven gegevens naar het view-bestand en laat de bedrijfslogica en de rest in de controller, waardoor ze allebei volgens afspraak schoner blijven, maar ook met minder toegang tot elkaar dan webformulieren toestaan.

Opmerkingen

• WANNEER moeten webformulieren de voorkeur krijgen boven MVC? Dit geeft geen antwoord op de oorspronkelijke vraag van de posters.
• @WeekendWarrior – Als je meer server-side toegang tot de client wilt, kies dan voor webformulieren. Als je meer ontkoppeling van de client / server in je code wilt, kies dan voor MVC. Aan het eind van de dag doen ze allebei precies hetzelfde. Reroute-filters doen hetzelfde als de MVC-urls en u kunt webformuliercode naar een aparte middelste laag verplaatsen om deze meer te ontkoppelen. weblogs.asp.net/scottgu/archive/2010/01/24/…
• Wat betreft uw derde punt, die bedrijfslogica komt terecht in het .aspx.cs-bestand – ik denk dat dit de schuld is van ontwikkelaars. Het ‘ is / zou er niet moeten / zijn. In webformulieren is .aspx de ” weergave “, de .aspx.cs is de ” controller ” equivalent, bedoeld om de code te verwerken die alleen rechtstreeks betrekking heeft op de gebruikersinterface door een bedrijfslaag of grofkorrelige bedrijfsgevellaag te pollen. Het feit dat mensen bedrijfslogica in .aspx.cs stoppen, is gewoon een slechte programmering. Ze kunnen ook de bedrijfslogica in MVC recht in de weergave zetten! MVC dwingt ‘ geen scheiding van deze dingen af.
• In wezen heeft hij meer gelijk dan andere antwoorden die hier worden gepost. ASP.net is het basisidee achter een modulaire webtechnologie-familie, zoals gemaakt door Microsoft. ASP.net MVC-module is misschien een tijdelijke hype, maar het is zeker niet de laatste, het begint allemaal met ASP.net, dus wanneer je ASP.net moet kiezen, als je niet denkt dat MVC niet jouw ding is, misschien ben je ergens meer in geïnteresseerd anders OWIN of …, iets geavanceerder, of je eigen raamwerk voor je taken gemaakt. Misschien heb je ASP.MVC niet eens nodig en sla je het over en ga je naar Owin of Katana, maar gebruik je asp.net

Naar mijn mening zijn ze voldoende verwant en hebben ze ongeveer dezelfde mogelijkheden die ze zouden moeten hebben afhankelijk van uw voorkeur.

Een geweldige WebForms-ontwikkelaar kan een product produceren dat even krachtig is als een geweldige MVC-ontwikkelaar. Maar de geweldige WebForms-ontwikkelaar die zichzelf probeert te dwingen MVC te adopteren, komt te kort. Hetzelfde geldt voor een geweldige MVC-ontwikkelaar die WebForms een kans geeft.

Het zijn geen volledig afzonderlijke entiteiten, en zolang Microsoft beide blijft ondersteunen, denk ik dat je voor elk een gemengde groep van uitzonderlijke ontwikkelaars zult zien.

Dit gaat allemaal over persoonlijke keuze, ervan uitgaande dat we allemaal bekwaam zijn met de technologie die we gebruiken. Ik gebruik de ontwerpbenadering van WebForms al vele jaren en ik moet zeggen dat het enige nadeel is dat vanwege de simplistische benadering veel mensen niet de tijd nemen om de enorme mogelijkheden ervan te ontrafelen.

Ik heb onlangs MVC gebruikt om een project te voltooien, en hoewel ik de ontwerpbenadering van applicatie-ontwikkeling (die je meer controle geeft, schone URLs, SOC, enz.) best vind, is er echt niet veel , dat WebForms niet kan. In feite heeft de opkomst van jQuery en zijn werking met WebForms (evenals MVC) deze argumenten minder een probleem gemaakt. En wanneer mensen praten over het scheiden van zorgen als een voordeel dat MVC heeft ten opzichte van MVP, vraag ik hen hoeveel ze weten van Objectgeoriënteerd programmeren en hoeveel ze het principe van abstractie en polymorfisme toepassen.

Ik ben momenteel comfortabel met het gebruik van beide technologieën en ik kies en kies op basis van de situatie. Eerlijk gezegd is het aan voor jou, maar de waarheid blijft dat niet iedereen de tijd neemt om diepgaand te leren waartoe een bepaalde technologie in staat is.

Opmerkingen

• Idem over de enorme mogelijkheden van webformulieren. De meeste mensen zien de zijwieltjes van webformulieren en vergelijken dit met MVC.
• Het heeft weinig zin om een abstractie te leren bovenop HTML en Javascript in deze tijd (zelfs in 2013). Het ‘ is niet goed voor uw toekomstige kansen. HTML en Javas cript is prima zoals het is. Het is een verloren strijd.

Wanneer ik met een programmeerprobleem word geconfronteerd, kijk ik vaak naar het internet voor antwoorden. Webforms heeft heel veel informatie / componenten om zo ongeveer alles te doen. In MVC heeft het feit dat er minder bronnen online zijn en de lagen abstracties die nodig zijn om iets te laten werken, een limiet gesteld aan dingen die ik ooit zou kunnen doen. MVC-totaal maakt mijn productiviteit als ontwikkelaar kapot, terwijl het met Webforms niet is. Dus voorlopig blijf ik bij webformulieren totdat MVC voldoende volwassen is om het te vervangen.

Welnu, WebForms hebben meer leermiddelen beschikbaar (simpelweg vanwege het feit dat het ouder is) en dus zullen nieuwe programmeurs die “niet” op de hoogte zijn “sneller vinden informatie over deze oudere technologie in tegenstelling tot de nieuwere dingen zoals MVC.

Senior / ervaren programmeurs zijn ouder en zullen meer bedreven zijn in de oudere technologie vanwege het feit dat ze er langer in hebben geprogrammeerd dan zij hebben in de nieuwere.

Tenzij u het geld en de moeite kunt besteden om uw mannen net zo bekwaam te maken in MVC als in WebForms-toepassingen, zult u ongetwijfeld proberen te wachten met upgraden naar de nieuwe platform zo lang mogelijk.

Het levert dus verschillende logistieke problemen op: Wegen de voordelen van MVC op tegen de kosten in termen van mindere kwaliteit en implementatietijd? Als ik een site heb die volledig in WebForms is geschreven, zou het dan de moeite en het geld waard zijn om MVC erin te integreren?

Zoals gezegd door een eerdere commentator, verhindert MVC u ook om hetzelfde niveau van interface te bereiken met de controller zoals u zou kunnen met WebForms. Hoewel ik helemaal voor de kant van de dingen ‘Voorkom dat de gebruiker dingen volstopt / leert’, kan het voor teams nog steeds onredelijk lastig zijn om een programma te implementeren / implementeren dat zich fanatiek aan dat paradigma houdt voor alles wat ze schrijven.

Ik denk dat de kloof tussen deze twee technologieën niet zo groot is als vroeger.

• Webformulieren kunnen de routeringsengine gebruiken die MVC gebruikt (of iets vergelijkbaars).
• De scriptmanager kan scripts combineren, laden vanaf een CDN en zelfs het laden van scripts uitstellen.

Om je vraag direct te beantwoorden, denk ik dat het aankomt op voorkeur en / of wat het project is. Ze hebben allebei een significant andere benadering van ontwikkeling. Persoonlijk heb ik gewerkt aan de overgang naar MVC, maar geniet nog steeds van het werken met webformulieren. Ik denk dat het antwoord op de vraag of je MVC of webformulieren moet gebruiken, is dat je beslist door beide technologieën te ervaren.

Reacties

• Webformulieren en MVC bevelen standaard een radicaal andere houding aan bij webontwikkeling, dit is belangrijk , weinig ontwikkelaars wijken hiervan af van ” de standaard “. Beiden kunnen echter worden gebruikt om hetzelfde te bereiken.