Dat zeg ik niet,
er zijn zek
er dingen in WebForms die bet
er zoden kunnen (zolas de ViewState). Dingen die ik fijn vind aan WebForms zijn us
ercontrols (h
erbruikbare functionaliteit), databinding en code behind.
Dat ik in een view een listview ne
erdrop en vanuit code behind invloed kan uitoefenen op hoe de boel zich gedraag tijdens rend
eren (OnItemDataBound) vind ik een stuk prettig
er w
erken dan in MVC waar markup en control-logica door elkaar heen lopen.
Ik kan een listview die ik in MVC heb gebouwd niet zomaar naar een design
er sturen ("Pas jij deze tabel even aan?") omdat het vol staat met stukjes code die een design
er niets zeggen. Dit in tegenstelling tot een WebForms-view, waar amp
er iets aan logica in staat. Het enige wat ik tegen een design
er hoef te zeggen is "Laat die asp:runat en ID-tags met rust".
Misschien hebben mijn opdrachtgev
ers gewoon hele vreemde eisen, waardoor ik telkens tegen de limieten van WebForms aanloop

Beide technologieën hebben hun st
erke en zwakke punten. Ik ben nog nooit tegen limieten van WebForms of MVC aangelopen.

Toegegeven, omdat het al heel lang is doorontwikkeld zijn er een batterij controls voor waar je akelig van wordt. Dat maakt het RAD aspect van Webforms wel aantrekkelijk. Maar ik mis gewoon de flexibiliteit van MVC.
Er zijn vrij veel vendors van componenten, dat is de kracht van WebForms. Ik gebruik ze ov
erigens bijna nooit. Ik heb één ke
er op een project gew
erkt waar men wel te pas en te onpas 3rd party components voor gebruikte (zelfs voor een button) en dat was geen topp
ertje. Eigenlijk zouden die controls met zo'n cheesy slogan moeten komen:
Geniet, maar gebruik met mate.
"Flexibiliteit van MVC" moet je me even uitleggen, want voor mijn gevoel dwingt MVC je juist me
er in een vast stramien dan WebForms. (Niet dat dat slecht is, integendeel!)
Helemaal als er geavanceerde scenario's met ajax gevraagd worden. UpdatePanel (of de Telerik variant) blijft gewoon behelpen. (wat voornamelijk komt door het page life-cycle model).
Eens. Als
er niets is wat in de ViewState dingen moet wijzigen moet je updatepanels niet gebruiken.
Ik heb ze wel eens gebruikt in een SharePoint-project, dat was vooral vanwege de "wow"-factor bij de klant. Ik had niet veel tijd maar vond een volledige postback visueel onzinnig, een UpdatePaneltje erin gooien kostte zo goed als geen tijd terwijl het de pagina visueel veel aantrekkelijker maakte.Ik betrap mezelf er ook steeds meer op dat ik gewoonweg MVC controllers introduceer in een WebForms project om eenvoudige ajax endpoints e.d. te creëren. (en als je die 2 niet wil mixen zou je altijd nog terugkunnen vallen op (oude) asmx services, al ben je daar weer meer beperkt met je mogelijkheden).
Als ik AJAX-dingen wil doen in een WebForms-project maak ik een .asmx aan of voeg ik Web API toe. V
ervolgens lekk
er aan de slag met XMLHttpRequest, jQu
ery of welke technologie
er dan ook gebruikt wordt.
Ik heb een ke
er in een project een aantal widgets (die gebruik maakten van PageMethods en and
ere lelijke zooi) v
ervangen door een webs
erviceje die precies de juiste informatie retourne
erde. Het resultaat zag
er precies hetzelfde uit, maar de pagina laadde een stuk snell
er.