[.NET] Microsoft MVC Framework voor ASP.NET

[Daspeed]

Een tijdje terug is bekend geworden dat Microsoft met een alternatief gaat komen voor Webforms binnen ASP.NET. Dit zal gaan gebeuren in de vorm van een MVC framework dat wel wat weg heeft van Monorail.

Zelf ben ik er erg blij mee dat ze met dit alternatief gaan komen. Webforms heeft zo zijn leuke dingen, maar over het algemeen vond ik het toch vaak een (onnodig) dikke abstractie op het hele web-gebeuren, waardoor simpele dingen soms toch nog ingewikkeld werden.

Monorail was wat mij betreft technisch gezien al een fijnere oplossing, maar als framework toch lastig om binnen een organisatie geadopteerd te krijgen. Want tjah, het is niet van Microsoft, er zijn niet veel mensen met kennis erover (hoewel Webforms lastiger te begrijpen is) en eventuele webcontrols die je hebt aangeschaft kun je er ook niet bij gebruiken.

Nu komt Microsoft dus zelf met een soortgelijke techniek waarbij denk ik de goede aspecten van deze twee frameworks gecombineerd zullen gaan worden. Ik kan eigenlijk niets anders zeggen dat ik het graag morgen al zou willen hebben

Wat denken jullie over deze stap van Microsoft?

Hier is overigens nog wat videomateriaal te vinden over de presentatie van het MVC framework.

[Not Pingu]

De doelstellingen zien er goed uit. Ook positief is dat dit als keuze naast het oude webforms model wordt aangeboden. Maar zoals het artikel dat TS linkt al opmerkt, Monorail biedt dit en meer.
Net als bij LINQ-to-SQL/Entity framework, denk ik dat MS te laat komt met een tool waar al betere alternatieven voor bestaan.

Wel is het mogelijk dat het feit dat het 'van Microsoft is', meer developers kan aanzetten om over te stappen op nieuwere ontwikkelmethoden, zowel voor MVC als O/R mapping.

[ Voor 62% gewijzigd door Not Pingu op 13-10-2007 15:56 ]

[EfBe]

Ik geloof er niets van dat dit een bruikbaar framework gaat worden. De ASP.NET crew heeft de afgelopen jaren elke keer weer laten zien net niet door te hebben dat wat ze maken een framework moet zijn en niet een product voor de sleur-n-pleur progger.

[Daspeed]

EfBe schreef op zondag 14 oktober 2007 @ 10:55:
Ik geloof er niets van dat dit een bruikbaar framework gaat worden. De ASP.NET crew heeft de afgelopen jaren elke keer weer laten zien net niet door te hebben dat wat ze maken een framework moet zijn en niet een product voor de sleur-n-pleur progger.

Nouja kijk het is natuurlijk altijd afwachten wat je krijgt, dat ben ik met je eens, maar wat ze tot nu toe hebben laten zien van dit framework en als je hun goals bekijkt dan ziet het er op zich goed uit. Daarnaast hebben ze nu natuurlijk al een sleur-en-pleur framework en wordt dit niet een framework dat Webforms gaat vervangen, maar wat gewoon een alternatief is.

Maar goed, alleen de tijd zal het ons vertellen Ik hoop alleen dat je ongelijk gaat krijgen

[Verwijderd]

Ik heb die video helemaal gekeken (duurt echt te lang ), en er is iets dat me direct opvalt. Ze hebben erg goed gekeken naar MonoRail en dergelijke, en eigenlijk hier en daar dingetjes vervangen door gave (nieuwe) .NET dingetjes.
Wat ik vooral interessant vind is dat je de webforms (inclusief master pages etc.) manier van werken gaat kunnen gebruiken, inclusief een fatsoenlijke intellisense en dergelijke. Dat mis ik toch wel een beetje als ik met MonoRail aan de slag ga. Ook vind ik webforms een stuk fijner werken (als frontend dan) dan bijvoorbeeld nVelocity. Kan ook liggen aan het feit dat ik gewoon een hoop met webforms heb gedaan, en minder met andere engines...

[edit]
Een groot voordeel van dit framework is, naast de testability (is dat een woord?), ook de toegankelijkheid. Geen ranzige javascripts meer voor postbacks!

Daarbij lijkt het (als je de video hebt gekeken) dat ze Atlas/asp.net+ajax willen inbouwen in het nieuwe framework. Als ze het dan voor elkaar krijgen dat je als je geen javascript hebt gewoon naar de betreffende controllers gelinkt wordt, is het helemaal geweldig ;-)

Ik kijk er in ieder geval positief tegenaan, en ik ben benieuwd naar de eerste beta versies...

[ Voor 28% gewijzigd door Verwijderd op 15-10-2007 00:49 ]

[Niemand_Anders]

@TedKees, AJAX zonder javascript is per definitie onmogelijk. Wil je weten waarom. Zoek maar eens op waar de 'J' uit AJAX voor staat.

Wel zul je inderdaad geen volledige postbacks meer krijgen. Aan de andere kant bleken Webforms (template + codebehind) zo goed te werken, dat ze hetzelfde model hebben gebruikt bij WPF. Een belangrijke toevoeging zie ik in de pluggable ViewEngine. Nu moet je kiezen uit overerving van Page of echt volledig zelf I(Async)HttpHandler(Factory) implementeren. Terwijl je vaak maar een kleine wijziging in de flow wilt maken en een extra property wilt toevoegen.

[Verwijderd]

Niemand_Anders schreef op dinsdag 16 oktober 2007 @ 13:18:
@TedKees, AJAX zonder javascript is per definitie onmogelijk. Wil je weten waarom. Zoek maar eens op waar de 'J' uit AJAX voor staat.

Wel zul je inderdaad geen volledige postbacks meer krijgen. Aan de andere kant bleken Webforms (template + codebehind) zo goed te werken, dat ze hetzelfde model hebben gebruikt bij WPF. Een belangrijke toevoeging zie ik in de pluggable ViewEngine. Nu moet je kiezen uit overerving van Page of echt volledig zelf I(Async)HttpHandler(Factory) implementeren. Terwijl je vaak maar een kleine wijziging in de flow wilt maken en een extra property wilt toevoegen.

Ik weet waar AJAX voor staat, ik doelde op een fatsoenlijke fallback optie als je geen javascript enabled hebt. Dat je dus als je bezoeker zonder javascript werkt, ge-reroute wordt naar je non-ajax action op je controller.
Misschien ligt dat ook wel bij de developer, maar 't zou toch tof zijn als e.e.a. door je framework wordt opgevangen

[Daspeed]

Meer info:
http://weblogs.asp.net/sc...sp-net-mvc-framework.aspx

[Niemand_Anders]

Verwijderd schreef op dinsdag 16 oktober 2007 @ 14:58:
Ik weet waar AJAX voor staat, ik doelde op een fatsoenlijke fallback optie als je geen javascript enabled hebt. Dat je dus als je bezoeker zonder javascript werkt, ge-reroute wordt naar je non-ajax action op je controller.
Misschien ligt dat ook wel bij de developer, maar 't zou toch tof zijn als e.e.a. door je framework wordt opgevangen

Volgens mij heeft AJAX dat al. Uiteraard werken een aantal onderdelen (timers) dan niet meer, maar volledige 'ouderwetse' postbacks zijn nog steeds mogelijk. Echter ben je dan wel zeer beperkt. Zo kun je dan niet meer het click event afvangen, omdat het event niet wordt afgevuurt.

Door alle buttons dezelfde naam te geven (niet te verwarren met id) kun je later toch bij een volledige postback bepalen op welke button er werd geklikt.

Het is niet voor niets dat experts alleen AJAX technologie toejuigen als het een extra toegevoegde waarde heeft waarmee dus partial updates mogelijk zijn.

Persoonlijk ga ik bij al mijn (onze) websites er vanuit dat javascript uitstaat. Veel grote bedrijven zetten namelijk javascript namelijk per group policy uit waardoor de kans op browser infecties (vage popups) een stuk kleiner wordt. Zeker in de financiele (banken en verzekerings maatschappijen) branch waarin wij werkzaam zijn is dit het geval.

Staat javascript aan, dat heeft dat alleen als toevoeging dat er geen volledige postbacks meer nodig zijn.

[Verwijderd]

EfBe schreef op zondag 14 oktober 2007 @ 10:55:
Ik geloof er niets van dat dit een bruikbaar framework gaat worden. De ASP.NET crew heeft de afgelopen jaren elke keer weer laten zien net niet door te hebben dat wat ze maken een framework moet zijn en niet een product voor de sleur-n-pleur progger.

Hoewel ik je frustratie wel begrijp, sla je nu de plank volledig mis. Ze snappen het dondersgoed en ze bieden nu juist voor jou een alternatief aan. Je moet echt even het filmpje bekijken dat in de 1e post gelinkt is. Scott Guthrie (die overigens al jaren de indruk wekt het allemaal 110% te snappen) geeft diverse keren aan dat ze uitgebreid gekeken hebben naar andere frameworks (Ruby on Rails, Django, MonoRail) en verdedigt waarom ze soms andere keuzes hebben gemaakt.

Edit:
Check bijvoorbeeld dit antwoord van Scott Guthrie om te zien dat ze het wél snappen:

Hi Andrew,

>>>>>>>Are you planning to introduce some of the other functionality associated with Rails/Django et al.?
>>>>>>> - respond_to, e.g. /posts/1.xml returns us XML data? Handy for REST type applications...
Yes.
>>>>>>> - Nested resources: e.g. /posts/1/comments
Yes.
>>>>>>> - controller filters: e.g. before_filter :check_security
Yes.

Hope this helps,

Scott

Ik kijk er wel naar uit, ik ben die postback en page lifecycle een beetje zat, en het schrijven van ProductsGridView_RowDataBound(object sender, SpecialeEventArgsVoorDezeHandler e) heb ik ook wel gezien. Wel jammer dat een hoop webcontrols niet meer zullen werken in de views, maar mischien heb je nu aan een repeater genoeg.

Ze gaan nieuwe webcontrols schrijven, ik maak me hier wel een beetje zorgen over. Ze moeten dan dus 2 sets webcontrols gaan bijhouden, voor webforms en voor MVC views. Dat geld ook voor de ASP.NET Ajax controls. En dan heb ik het nog niet eens over de Ajax Control Toolkit. Ga je nu verschillen zien tussen deze twee, bijvoorbeeld alleen een TreeView control voor webforms of alleen non-postback paging controls voor MVC views?

Het webforms model is leuk voor de beginnende programmeur die in design view werkt en dubbel klikt om een event handler in de code behind te maken, maar MVC is toch beter te begrijpen, overzichtelijker en voelt 'lichter' aan dan webforms. Jammer dat het net niet op tijd is voor VS 2008, maar ik ga er toch wel mee werken als de CTP uit is.

[ Voor 11% gewijzigd door Verwijderd op 18-10-2007 10:24 ]

[EfBe]

Verwijderd schreef op donderdag 18 oktober 2007 @ 10:19:
[...]
Hoewel ik je frustratie wel begrijp, sla je nu de plank volledig mis. Ze snappen het dondersgoed en ze bieden nu juist voor jou een alternatief aan. Je moet echt even het filmpje bekijken dat in de 1e post gelinkt is. Scott Guthrie (die overigens al jaren de indruk wekt het allemaal 110% te snappen) geeft diverse keren aan dat ze uitgebreid gekeken hebben naar andere frameworks (Ruby on Rails, Django, MonoRail) en verdedigt waarom ze soms andere keuzes hebben gemaakt.

Dat Scott het snapt, weet ik wel, maar dat het team om hem heen het niet snapt, daar kan hij weinig aan veranderen, hij maakt nl. niet de code.

Wat falikant fout gegaan is in asp.net is dat ze geprobeerd hebben er een form-oriented framework van te maken dat lijkt op de al bekende form-oriented frameworks als winforms en de UI spullen van VB6. Maar dat werkt niet wanneer je het stateless maakt zoals zij hebben gedaan: dan krijg je narigheid van de bovenste plank, waarbij je de page lifecycle moet kennen om iets te kunnen doen, waar je zelf je form member variables moet babysitten omdat het framework dat niet kan, etc. etc.

laten we ophouden met die crap en gewoon erkennen dat web gewoon HTML is en niet meer dan dat en dat er dus niet iets bestaat als een stateful form, maar dat je gewoon HTML moet renderen, en niets meer en niets minder.

ALS dit MVC framework dat inderdaad gaat doen, prima, maar ik voorzie nog altijd dat veel declaritive wordt opgelost (wat niet werkt, je krijgt geknoei in de HTML van inline code in tags om attributes te zetten etc.) en daarnaast dat het stateful lijkt maar het niet is.

Ik kijk er wel naar uit, ik ben die postback en page lifecycle een beetje zat, en het schrijven van ProductsGridView_RowDataBound(object sender, SpecialeEventArgsVoorDezeHandler e) heb ik ook wel gezien. Wel jammer dat een hoop webcontrols niet meer zullen werken in de views, maar mischien heb je nu aan een repeater genoeg.

Ze gaan echt dat niet overboord zetten. En vergeet niet, de mensen die dat verzonnen hebben zitten ook aan de knoppen van dit framework. Als jij dan verwacht dat ze nu WEL alles extensible maken en non-sealed/non-internal, dan begrijp ik niet waarom ze dat in de vorige 2 versies zo ongelovelijk NIET gedaan hebben.

Ze gaan nieuwe webcontrols schrijven, ik maak me hier wel een beetje zorgen over. Ze moeten dan dus 2 sets webcontrols gaan bijhouden, voor webforms en voor MVC views. Dat geld ook voor de ASP.NET Ajax controls. En dan heb ik het nog niet eens over de Ajax Control Toolkit. Ga je nu verschillen zien tussen deze twee, bijvoorbeeld alleen een TreeView control voor webforms of alleen non-postback paging controls voor MVC views?

Ik dacht dat jij dacht dat het wel goed zou komen?

Kijk, ScottGu is een beste kerel, altijd vriendelijk en behulpzaam. Het punt is echter dat hij erg hoog in de organisatie zit en de mensen die de details uitwerken zitten daar ver onder. Verder is er een 'visie' voor asp.net die niet 1 2 3 weggeflikkerd wordt en die dus wel dit design ook beinvloedt.

Het webforms model is leuk voor de beginnende programmeur die in design view werkt en dubbel klikt om een event handler in de code behind te maken, maar MVC is toch beter te begrijpen, overzichtelijker en voelt 'lichter' aan dan webforms. Jammer dat het net niet op tijd is voor VS 2008, maar ik ga er toch wel mee werken als de CTP uit is.

Veel mensen snappen MVC niet. Dit komt omdat verreweg de meeste mensen die UI's bouwen OF uit de asp/php hoek komen waar je HTML ziet met code er tussen (en ze hebben nog een punt ook) OF uit de winforms/VB hoek waar de forms stateful zijn en je niet te maken hebt met viewers en controllers, want die zijn samengeprakt in het form. Dat werkte 'goed' dus waarom veranderen naar iets moeilijks waar je veel eigen code moet schrijven?

[kenneth]

EfBe schreef op donderdag 18 oktober 2007 @ 14:10:
Dat werkte 'goed' dus waarom veranderen naar iets moeilijks waar je veel eigen code moet schrijven?

Ja, waarom? Ik vind MVC erg elegant, en zodra hier een CTP van is zal ik er zeker mee gaan kloten, maar in de meeste gevallen 'werkt' webforms gewoon. Met pagina's van 50kb omdat ViewState niet gesnapt wordt, maargoed

[Verwijderd]

kenneth schreef op donderdag 18 oktober 2007 @ 15:46:
[...]
Ja, waarom? Ik vind MVC erg elegant, en zodra hier een CTP van is zal ik er zeker mee gaan kloten, maar in de meeste gevallen 'werkt' webforms gewoon. Met pagina's van 50kb omdat ViewState niet gesnapt wordt, maargoed

Ik denk ook niet dat je dit moet zien als oplossing voor 'simpele' websites. Je kan MVC VEEL beter testen, je kan de hele zaak ook VEEL beter opsplitsen onder verschillende development teams. Je kan in principe alle drie de onderdelen (Model, View en Controller) apart ontwikkelen en dan werkt 't in principe gewoon.
MVC is ook heerlijk voor test driven development, omdat je simpelweg je controllers zonder views kan ontwikkelen, daar (unit) tests op los laten en eigenlijk al redelijk zeker weten dat alles werkt zoals gespecificeerd voordat je ook maar een regel van je views hebt geschreven. De view is daardoor ook echt alleen maar een schilletje om de gegevens uit je controller geworden.

Komt wel een probleempje bij: goede testcases schrijven en je requirements goed definieren is voor velen een vak apart ;-)

[Verwijderd]

EfBe schreef op donderdag 18 oktober 2007 @ 14:10:
...ALS dit MVC framework dat inderdaad gaat doen, prima...

Daar ga ik voor het gemak wel vanuit. Daarmee is het 'probleem' met webforms opgelost, en dan zou de gebruikelijke kritiek moeten verstommen. Voordat het uit is hebben we alleen dat ene filmpje van een uur om ons oordeel te vellen, en dat zag er gewoon heel goed uit.

Je hebt het filmpje niet bekeken, dat zie ik aan je reactie. De postback gaat wél overboord in het MVC model van Microsoft, dat wordt letterlijk met zoveel woorden gezegd. Dus het verhaal van stateful gaat ook verdwijnen, precies wat jij graag ziet, dus ik begrijp niet dat je niet enthousiast bent (ik wel namelijk).

En ze maken ook alles 'extensible' in die zin dat je zelf je de view engine kan verwisselen, dat je de routering ook kan verwisselen, dat ze nu wél een IHttpRequest en IHttpContext hebben (dus die kun je zelf implementeren voor je tests) en dat ze alle gangbare IoC frameworks werkend hebben. Je kunt ook kiezen om IController te implementeren, te erven van Controller of helemaal niets van die twee.

Kijk a.u.b. het filmpje en zie al je zorgen besproken worden. Of werk je helemaal niet met ASP.NET en gebruik je dit topic alleen om de valide doch oude kritiek over webforms te spuien?

[ Voor 51% gewijzigd door Verwijderd op 18-10-2007 19:15 ]

[EfBe]

Verwijderd schreef op donderdag 18 oktober 2007 @ 19:11:
[...]
Daar ga ik voor het gemak wel vanuit. Daarmee is het 'probleem' met webforms opgelost, en dan zou de gebruikelijke kritiek moeten verstommen. Voordat het uit is hebben we alleen dat ene filmpje van een uur om ons oordeel te vellen, en dat zag er gewoon heel goed uit.

Je hebt het filmpje niet bekeken, dat zie ik aan je reactie. De postback gaat wél overboord in het MVC model van Microsoft, dat wordt letterlijk met zoveel woorden gezegd. Dus het verhaal van stateful gaat ook verdwijnen, precies wat jij graag ziet, dus ik begrijp niet dat je niet enthousiast bent (ik wel namelijk).

Even wat uitleggen: ik kom nogal vaak in aanraking met wat ik altijd 'demoware' noem, vanuit Microsoft. het ziet er allemaal geweldig uit, het werkt altijd fantastisch... de visie is goed etc. althans, binnen de grenzen van de demo.

Dat is nog nooit anders geweest. Nu wel? nee, geloof me, dat is echt niet zo.
Sinds 1993 is er geen reet veranderd mbt wat een webpage is: het is platte HTML en sinds eind jaren 90 ook met javascript. Dat is nooit veranderd. Als ik een page opvraag van een server, dan krijg ik HTML en javascript. Dan kun je wel moeilijk doen op de server, maar daar ga jij het fenomeen HTML en javascript niet mee wegpoetsen.

De postback overboord? Dat kan alleen wanneer de volledige page in de browser draait en alle data beschikbaar is OF via ajax kan worden aangeleverd. Nu is ajax niet altijd mogelijk (security) en dus is het lang niet altijd zo dat je even een page maakt met een grid met een page uit een grote resultset ZONDER postbacks, dan kan nl. gewoonweg niet.

En dan gaat die postback overboord? Dat KAN niet, want jij krijgt page 2 van de data niet uit de page geperst wanneer page 2 niet in de page zit. Je moet dan naar de server terug. En dit is geen kleinigheid, want wellicht heb je met entity objects te maken en waar worden die dan bewaard? Je hebt dan te maken met state in die entities die wellicht gewijzigd is en wie gaat dat syncen? Dat gaat echt niet vanzelf.

Het werkt alleen als de view in de browser een javascript based view is die gevoed wordt door een webservice, maar dat is niet wat MVC is.

En ze maken ook alles 'extensible' in die zin dat je zelf je de view engine kan verwisselen, dat je de routering ook kan verwisselen, dat ze nu wél een IHttpRequest en IHttpContext hebben (dus die kun je zelf implementeren voor je tests) en dat ze alle gangbare IoC frameworks werkend hebben. Je kunt ook kiezen om IController te implementeren, te erven van Controller of helemaal niets van die twee.

Kijk a.u.b. het filmpje en zie al je zorgen besproken worden. Of werk je helemaal niet met ASP.NET en gebruik je dit topic alleen om de valide doch oude kritiek over webforms te spuien?

Om in asp.net land te bllijven: ik heb 2 datasource controls gemaakt die meer functionaliteit hebben dan die van MS bij elkaar, en om dat te toen moet je echt elke byte snappen hoe een webform werkt anders kom je er niet uit (leaky abstraction, anyone?). Webforms zijn een brakke abstractielaag die gewoon leuk leek maar het niet is, omdat je de innerlijke werking ervan moet begrijpen (volgorde van events etc.) voordat je iets kunt. Dit is een fundamentele flaw. dezelfde mensen gaan jou nu een MVC framework brengen. Ik verwacht er niet veel van.

Wat je ook vergeet is dit: toen ik in 1994 mijn eerste webpage maakte en mn eerste server-side driven site met perl (cgi's) was het vrij duidelijk wat gedaan moest worden. Dat hele principe is eigenlijk nooit veranderd: via de voorganger van asp (htc files) en ASP.NET is het nog altijd zo dat je gewoon HTML rendert op de server en dat daarna de server klaar is. De postback komt bij de server aan en daar is alles dus weg en moet opnieuw worden opgebouwd. In andere web platforms is het nog steeds hetzelfde: je rendert html, je bent volledig in sync met wat er WERKELIJK gebeurt. In ASP.NET is dat volledig zoek: je weet niet wat er gebeurt want dat zie je niet, echter je moet wel weten wat er gebeurt want anders kun je niet bepaalde dingen maken (komt een button click event voor of na de bind van grid met datasource? )

Dus per saldo is men laag op laag op laag gaan stapelen, maar feitelijk is er niets veranderd: er zijn alleen meer problemen bij gekomen. (want met perl een webpage renderen is echt niet zo moeilijk). Nu komt er een MVC framework, en dat is leuk voor degenen die dat willen gaan gebruiken, maar ten eerste gaat 99% van de developers er kompleet mee door het ijs, want het matched niet met hoe HTML werkt en niet met hoe ASP.NET werkt en ten tweede is ASP.NET an sig gewoon flawed to the bone, dus het moet niet IN ASP.NET zitten maar het compleet vervangen en het moet gebouwd worden door een ander team, niet het team wat ASP.NET gebouwd heeft. Dat zie ik niet gebeuren.

(edit). Tuurlijk lijkt het leuk, en lijkt het alsof ze het nu allemaal snappen etc. maar feitelijk is het gewoon een resultaat van niet nadenken. IS MVC wel DE manier om webpages te maken? MVC is niet een WEB pattern, maar een APPLICATION pattern. De M is niet iets van de UI laag, en de controller is feitelijk dat ook niet. De viewer is feitelijk dus de enige die in de web laag thuis hoort.

Een DataSource control op een page is feitelijk nu al een controller die een model beheert en die wordt gebruikt door de viewer (page). Je kunt je code feitelijk al testen met een datasource, want de methods die aangeroepen worden door de bound controls zijn gewoon public.

Maar wanneer je dat gaat proberen kom je erachter dat feitelijk daar het probleem niet zit. De hele lifecycle van de data in een form (of beter: wat die data voorstelt, semantisch) is iets wat je feitelijk niet kunt overlaten aan generieke code want het is de kern van jouw applicatie. M.a.w.: je moet het zelf schrijven, dus hoe men process pages maakte in asp. Maar dat wil men niet, men wil dat laten doen door een framework. Dat is prima, maar dan krijg je magic die je wellicht niet wilt. Voorbeeld: wanneer je een page van 10 customer entities in een grid stopt en die page gaat naar de browser. De user verandert van 3 het adres en klikt op 'Save'.

Wat gebeurt er dan? Wat de developer wil is dat op de server de customer entities die gewijzigde data krijgen zodat ze kunnen worden verscheept naar de logica die er verder iets mee gaat doen (bv saven). Dat wil de developer niet zelf doen. Echter OMDAT men dat niet wil, en terecht, moet je het overlaten aan een framework en dat heeft een prijs: OF magic code wat allerlei randvoorwaarden heeft (bv de huidige datasourcecontrols) OF handgeschreven code wat feitelijk neerkomt op het schrijven van process pages en je het zelf toch loopt te doen (op zich niets mis mee, maar als je je het dan realiseert, waarom gebruik je dan nog een framework wat niet matcht met hoe HTML werkt? )

[ Voor 17% gewijzigd door EfBe op 19-10-2007 10:00 ]

[Verwijderd]

Je hoeft echt niet een heel verhaal over HTML/Javascript en de nadelen van webforms te vertellen in een thread waar ASP.NET programmeurs posten. Het verhaal van de leaky abstraction en enorme viewstates is allemaal bekend (bij mij wel iig, en ik ben niets vergeten hoor).

Die kritiek die jij hebt op webforms (en ik ook hoor), die wordt juist door MVC opgelost. ASP.NET MVC framework heeft geen viewstate en geen postback (ook geen page lifecycle, de page behind erft van ViewPage en niet Page en mist die events). Je kan gewoon precies de HTML renderen die je wilt, en POSTen waarnaartoe je maar wilt.

...dezelfde mensen gaan jou nu een MVC framework brengen. Ik verwacht er niet veel van...

...ten eerste gaat 99% van de developers er kompleet mee door het ijs, want het matched niet met hoe HTML werkt en niet met hoe ASP.NET werkt en ten tweede is ASP.NET an sig gewoon flawed to the bone...

...maar feitelijk is het gewoon een resultaat van niet nadenken...

Is dat een flame? Prima joh, dan kan ik je ook nooit overtuigen. Maar doe jezelf een plezier, als het uitgebracht is, kijk er tenminste even een middagje naar, ik denk dat je dan aangenaam verrast zult zijn.

PS.
Het zal nooit al de problemen oplossen die jij noemt (syncen van wijzigingen in data en wat al niet meer) maar ik wens je veel succes daarmee, want dat zijn heel lastige vraagstukken. Hoewel de LINQ to SQL DataContext dat misschien kan (met Attach() kun je wijzigingen bijhouden en met SubmitChanges() kun je synchroniseren) maar dat zal jij ook wel 'flawed to the bone' vinden?

• As a testament to the good design of the existing ASP.NET platform (minus WebForms,) no changes were needed in ASP.NET to make the MVC framework a reality.
• LINQ to SQL : Handling disconnected CRUD operations in ASP.NET

[EfBe]

Verwijderd schreef op vrijdag 19 oktober 2007 @ 11:56:
Die kritiek die jij hebt op webforms (en ik ook hoor), die wordt juist door MVC opgelost. ASP.NET MVC framework heeft geen viewstate en geen postback (ook geen page lifecycle, de page behind erft van ViewPage en niet Page en mist die events). Je kan gewoon precies de HTML renderen die je wilt, en POSTen waarnaartoe je maar wilt.

We zullen zien, ik geloof er niet in, en jij wel, dus de toekomst zal het leren

Is dat een flame? Prima joh, dan kan ik je ook nooit overtuigen. Maar doe jezelf een plezier, als het uitgebracht is, kijk er tenminste even een middagje naar, ik denk dat je dan aangenaam verrast zult zijn.

Ik krijg al die maanden knoeien met hun troep op diepe niveaus in ASP.NET's core code echt niet terug, en dat vergeef ik ze nooit helemaal (en dat weet Scott, hij vond wel dat ik gelijk had daarin en dat ze het gingen verbeteren in de toekomst... nog niet veel gezien daarvan overigens)

PS.
Het zal nooit al de problemen oplossen die jij noemt (syncen van wijzigingen in data en wat al niet meer) maar ik wens je veel succes daarmee, want dat zijn heel lastige vraagstukken. Hoewel de LINQ to SQL DataContext dat misschien kan (met Attach() kun je wijzigingen bijhouden en met SubmitChanges() kun je synchroniseren) maar dat zal jij ook wel 'flawed to the bone' vinden?

Dat IS ook flawed to the bone, want er is geen n-tier ondersteuning en die attach troep is echt te dom voor woorden. Dinesh heeft op zn weblog aangegeven dat RTM van linq to sql gewoon geen support heeft voor n-tier architecturen, dus dat je change tracking met de hand moet gaan doen. Nu mag jij dat iets vinden wat niet erg is, maar aangezien jij daar dan tijd aan moet besteden en dus code moet gaan schrijven en dus bugs kan introduceren en jouw concurrentie een andere tool gebruikt die het wel netjes heeft opgelost, heb jij een nadeel tov de concurrentie.

Nu maakt mij dat niet zo uit, maar ik zou mn kop niet in het zand steken daarvoor als ik jou was. Nu snap ik een klein pietsie beetje van o/r mapping in .NET dus een beetje recht van spreken heb ik hopelijk wel.

• LINQ to SQL : Handling disconnected CRUD operations in ASP.NET

Mja. Ik kan het in 0 regels code, volledige change tracking over multiple tiers, services, maakt niet uit. Zij niet. Toch gek, denk ik dan. Men kan dan wel roepen dat het allemaal niet zo'n vaart loopt, maar mensen die er echt veel tijd in hebben gestoken weten wel beter. (en daar bedoel ik niet mezelf mee, maar bv Roger Jennigs met zn artikelen hierover:
http://oakleafblog.blogsp...-no-multi-tier-story.html

[Verwijderd]

...die attach troep is echt te dom voor woorden.

Ok man, bedankt voor de genuanceerde info. ASP.NET zuigt, Microsoft snapt er niets van, MVC zal dus ook wel zuigen, LINQ to SQL is vreselijk slecht, en jij kan het in 0 regels code...

[EfBe]

Verwijderd schreef op vrijdag 19 oktober 2007 @ 22:30:
[...]
Ok man, bedankt voor de genuanceerde info. ASP.NET zuigt, Microsoft snapt er niets van, MVC zal dus ook wel zuigen, LINQ to SQL is vreselijk slecht, en jij kan het in 0 regels code...

erm, ik KAN het ook in 0 regels code. Dom voorbeeld:

code:

<%@ Page Language="C#" AutoEventWireup="true"  CodeFile="Sample1.aspx.cs" Inherits="_Default" %>
<%@ Register Assembly="SD.LLBLGen.Pro.ORMSupportClasses" Namespace="SD.LLBLGen.Pro.ORMSupportClasses" TagPrefix="cc1" %>
<html>
<body>
    <form id="form1" runat="server">
        <h1>
            Northwind Customers</h1>
        <asp:GridView ID="GridView1" runat="server" AutoGenerateColumns="False" DataKeyNames="CustomerId" DataSourceID="_customerDS">
            <Columns>
                <asp:BoundField DataField="CustomerId" HeaderText="Customer Id" ReadOnly="True" SortExpression="CustomerId" />
                <asp:BoundField DataField="CompanyName" HeaderText="Name" SortExpression="CompanyName" />
                <asp:BoundField DataField="City" HeaderText="City" SortExpression="City" />
                <asp:BoundField DataField="Region" HeaderText="State" SortExpression="Region" />
            </Columns>
        </asp:GridView>
        <cc1:llblgenprodatasource2 id="_customerDS" runat="server" 
            adaptertypename="Northwind.DatabaseSpecific.DataAccessAdapter, NorthwindDBSpecific" 
            cachelocation="Session" datacontainertype="EntityCollection" 
            entityfactorytypename="Northwind.FactoryClasses.CustomerEntityFactory, Northwind">
        </cc1:llblgenprodatasource2>
    </form>
</body>
</html>

Geen code behind nodig, nergens een class nodig die de customers fetched en saved. Edit je customers en go. Change tracking in de entities, ik hoef niets te attachen bij postback, dat wordt geregeld.

Ik zeg niet dat linq to sql vreselijk slecht is, ik zeg alleen dat die attach reut echt slecht is, en daar ga jij nog wel achterkomen at runtime wanneer je een exception krijgt wanneer je een graph gaat attachen.

Tja, kennelijk mag je geen kritiek meer hebben tegenwoordig. Ik benoem wat er niet deugt, jij generaliseert mijn uitspraken, want dat komt jou goed uit, maar ik heb het niet zo gezegd zoals jij dat laat doorschemeren. Maar goed, kennelijk heb jij dat nodig om je gelijk te halen, c'est la vie.

[Verwijderd]

EfBe schreef op zaterdag 20 oktober 2007 @ 10:56:
Tja, kennelijk mag je geen kritiek meer hebben tegenwoordig.

Dat heb ik jou expliciet verboden inderdaad (pot/ketel?). Ik vind dat je gewoon onwijs negatief doet, en je zit behoorlijk te generaliseren en overdrijven (en daar beschuldig je vervolgens mij van, knap!), daar ben ik gewoon allergisch voor. Ooit ging het topic over MVC, maar ondertussen hebben de ASP.NET programmeurs er al flink van langs gekregen, MVC deugt op voorhand al niet (maar goed 99% van de mensen snapt dat toch niet), en sleep je er van alles en nog wat met d haren bij om toch maar vooral te kunnen klagen, wat je al niet eens consistent doet (ben je nou pro- of anti magische frameworks?).

Ik laat het laatste woord in deze aan jou, dus maak er wat moois van. Ik persoonlijk denk dat je een weblog moet beginnen...

[EfBe]

Verwijderd schreef op zaterdag 20 oktober 2007 @ 16:36:
[...]

Dat heb ik jou expliciet verboden inderdaad (pot/ketel?). Ik vind dat je gewoon onwijs negatief doet, en je zit behoorlijk te generaliseren en overdrijven (en daar beschuldig je vervolgens mij van, knap!), daar ben ik gewoon allergisch voor.

Mja, dat is niet mijn probleem.

Ooit ging het topic over MVC, maar ondertussen hebben de ASP.NET programmeurs er al flink van langs gekregen,

Tja, en dat bedoel ik dus: ik mag geen kritiek hebben op hoe ASP.NET in elkaar zit kennelijk. Bivakkeer jij maar eens 2 maanden onder de oppervlakte van dat framework, dan weet je wel beter. Inheritance? Wat is dat? Oh, ja we hebben het wel uitbreidbaar gemaakt, maar essentiele classes voor design time designers zijn sealed en internal...

MVC deugt op voorhand al niet

Waar zeg ik dat het MVC pattern niet deugt? Lijkt me knap, aangezien ik het MVC pattern an sig een goed pattern vind.

(maar goed 99% van de mensen snapt dat toch niet),

Jij wil beweren van wel dan? Verreweg de meeste mensen snappen nauwelijks hoe databinding werkt op winforms of webforms, en dan is MVC 'makkelijker'? Yeah right.

en sleep je er van alles en nog wat met d haren bij om toch maar vooral te kunnen klagen, wat je al niet eens consistent doet (ben je nou pro- of anti magische frameworks?).

Ik gaf alleen aan dat de focus op technische advancements ligt (meer abstraction layers) en niet op wat de developer nu eigenlijk ECHT nodig heeft. (en nee, dat is lang niet altijd MEER technische reut). I.p.v. meer naar php op te schuiven (en het moet ergens aan liggen dat Php verreweg de meeste websites runt), gaan ze er meer vanaf. Dat kan alleen wanneer je kunt onderbouwen dat de meeste ontwikkelaars baat hebben bij een move naar meer technische middelen, nog meer abstraction layers. Ik zie de argumentatie daarvoor niet terug, immers, een nieuwe abstractielaag kan alleen goed werken wanneer deze niet leaky is. ASP.NET is een leaky abstraction (anders zou je de page lifecycle niet hoeven weten bv). MVC in HTML land gebruiken werkt alleen als je HTML volledig kunt abstraheren mbv MVC. Gezien het stateless karakter van HTML-based services (websites/apps bv) zie ik dat als een zeer lastig karwei. Je krijgt het wel van de grond, maar altijd leaky. Dat levert dus per saldo niet minder complexiteit op, maar meer dan je wenst. Dit is dus IMHO niet een voordeel voor ontwikkelaars. Als ik terugkijk naar asp pages met in-line script, dan was de moeilijkheid daar louter de runtime errors die je compile time wilde hebben, maar puur en alleen dat, de rest was voorspelbaar en niet leaky.

Ik laat het laatste woord in deze aan jou, dus maak er wat moois van. Ik persoonlijk denk dat je een weblog moet beginnen...

Gast, zoek eens op 'Frans Bouma' op google. Kom je mn weblog en vele anderen die naar de mijne verwijzen wel tegen. (beluister bv eens het interview van DotNetRocks met me van een maandje of wat terug) .

Nog een tip: ik mag dan zeikerig overkomen, maar ik zeik niet zonder argumenten, als jij denkt van wel, dan moet je nog maar eens beter kijken.

[ Voor 15% gewijzigd door EfBe op 21-10-2007 11:20 ]

[Verwijderd]

EfBe schreef op vrijdag 19 oktober 2007 @ 09:41:
[...]
...

Nu is ajax niet altijd mogelijk (security) en dus is het lang niet altijd zo dat je even een page maakt met een grid met een page uit een grote resultset ZONDER postbacks, dan kan nl. gewoonweg niet.

En dan gaat die postback overboord? Dat KAN niet, want jij krijgt page 2 van de data niet uit de page geperst wanneer page 2 niet in de page zit. Je moet dan naar de server terug. En dit is geen kleinigheid, want wellicht heb je met entity objects te maken en waar worden die dan bewaard? Je hebt dan te maken met state in die entities die wellicht gewijzigd is en wie gaat dat syncen? Dat gaat echt niet vanzelf.

Ligt dit nou aan mij, of is dat punt met betrekking tot security nou klip klare onzin? Het enige wat AJAX doet is onderwater dezelfde informatie ophalen die je anders via een verse page refresh zou doen. Ik zie niet in waarom security een issue kan zijn. Wellicht kan jij m'n lampje laten branden Wel ben ik het met je eens dat postback niet zomaar overboord gegooid kant worden (je moet immers toch die tweede pagina ophalen). Daarnaast vind ik het ook een groot probleem dat wanneer je een overzicht hebt, de data wellicht gewijzigd is, die doorgaans niet gesynchroniseerd wordt. AJAX is een leuke saus, met een naar bijsmaakje.Het notifyen van alle views van het gewijzigde model is niet mogelijk bij webapplicaties, hoe je het ook wendt of keert.

[Verwijderd]

Verwijderd schreef op zondag 21 oktober 2007 @ 14:35:

Ligt dit nou aan mij, of is dat punt met betrekking tot security nou klip klare onzin? Het enige wat AJAX doet is onderwater dezelfde informatie ophalen die je anders via een verse page refresh zou doen. Ik zie niet in waarom security een issue kan zijn. Wellicht kan jij m'n lampje laten branden

Wat als door client-side security settings er geen javascript gebruikt mag worden? Of geen ActiveX? Het heeft niets met de security van de webapplicatie te maken, wel met die van de client c.q. user agent.

[kenneth]

Company policies hebben nog wel eens Javascript uit staan om veiligheidsredenen, en dus werkt AJAX dan niet

Wat Cheatah zegt dus

[ Voor 12% gewijzigd door kenneth op 21-10-2007 15:09 ]

[EfBe]

Verwijderd schreef op zondag 21 oktober 2007 @ 14:35:
[...]
Ligt dit nou aan mij, of is dat punt met betrekking tot security nou klip klare onzin? Het enige wat AJAX doet is onderwater dezelfde informatie ophalen die je anders via een verse page refresh zou doen. Ik zie niet in waarom security een issue kan zijn. Wellicht kan jij m'n lampje laten branden

Je moet het niet zien als "Oh jee, met Ajax ligt mn server open!", want dat is wat anders. Wat ik bedoel is dat je API aan de buitenkant informatie laat doorschemeren die je wellicht niet naar buiten brengt. Er is nl. een verschil in:
a) postback naar page, page doet intern van alles, data wordt gerenderd in HTML, html gaat terug
vs.
b) call naar service, parameters voor call gaan mee, data komt terug en hoe het verwerkt wordt is zichtbaar

Het kan goed zijn dat men niet een API wil openbaren die data manipulatie toestaat of aangeeft hoe data te verkrijgen is (als een browser nl. toegang heeft, heeft iedereen toegang), en dat hoef je niet bij een page-based systeem met postbacks, maar wel met een webservice based systeem.

Wel ben ik het met je eens dat postback niet zomaar overboord gegooid kant worden (je moet immers toch die tweede pagina ophalen). Daarnaast vind ik het ook een groot probleem dat wanneer je een overzicht hebt, de data wellicht gewijzigd is, die doorgaans niet gesynchroniseerd wordt. AJAX is een leuke saus, met een naar bijsmaakje.Het notifyen van alle views van het gewijzigde model is niet mogelijk bij webapplicaties, hoe je het ook wendt of keert.

Tuurlijk, maar dat is eigenlijk een gevolg van het stateless pull model wat je gebruikt bij HTML. Als je dat laat bestaan in je abstraction layer, dan is het zichtbaar, je weet dat je met een stateless HTML based applicatie bezig bent die niet net doet alsof hij stateful is. . Dus als je AJAX gebruikt en op een abstraction level waar HTML/HTTP niet is weggeabstraheerd, dan is het dus ook niet iets wat men verwacht te kunnen doen. Echter, verwacht men een stateful, connected systeem waarbij dingen mogelijk zijn die eigenlijk niet kunnen, dan is het inderdaad een probleem, maar IMHO ligt dat aan het feit dat men iets verwacht wat er niet is. Als de abstractielaag net doet alsof het er wel is, dan is de abstractielaag crap, is het echter iets wat tussen de oren van de developer zit, dan moet die op cursus of het boek nog eens lezen .

[Verwijderd]

Hoera! Scott Gutthrie heeft een enorm uitgebreide post op z'n blog gezet over het MVC framework (en een beetje VS2008). En 't is pas 'part 1'.

zie: http://weblogs.asp.net/sc...mvc-framework-part-1.aspx

[Daspeed]

Ah dat brengt al weer wat meer duidelijkheid. Ik hoop echt dat ze snel met een public preview komen.

[EfBe]

Verwijderd schreef op dinsdag 13 november 2007 @ 21:31:
Hoera! Scott Gutthrie heeft een enorm uitgebreide post op z'n blog gezet over het MVC framework (en een beetje VS2008). En 't is pas 'part 1'.

zie: http://weblogs.asp.net/sc...mvc-framework-part-1.aspx

Goede uitleg idd. Bied perspectief! (heee, gratis reclame, thanks ScottGu! )

1 ding vraag ik me wel af: hoe gaan ze 2-way databinding oplossen. Nu kan dat bijna zonder code (alleen maar HTML) met een slimme datasource control, maar met een controller waar de data naartoe moet eerst is dat IMHO lastig te doen. Op zich boeit databinding niet zo, IMHO, maar er zijn veel mensen waarvoor het een essentieel onderdeel is van hun werk.

[ Voor 29% gewijzigd door EfBe op 14-11-2007 09:36 ]

[Orphix]

Ik gebruik op dit moment al een MVC opzet in mijn ASP.NET applicaties. Echter is het wel een crime om dit goed te laten samenwerken met het WebForms model. Er zit gewoon teveel overhead bij en het is lastig om mijn applicaties lean and mean te krijgen (denk bv aan viewstate, teveel gebruik van postbacks, etc). Ik ben het eens met EfBe dat het webforms model op een aantal essentiele punten gewoon faalt en naarmate je applicatie groter en complexer wordt gaat dat steeds meer tegen je werken. Postbacks zijn erg handig, maar ik denk ook dat het teveel overgebruikt wordt. Veel pagina's kunnen worden opgezet via een simpele GET met wat parameters. Daarnaast werk ik zelf ook zelden met de visuele designer; gebruik mijn .aspx enkel om controls te declareren en probeer zoveel mogelijk in mijn code-behind, of liever nog in aparte libraries op te lossen.

Voor zover ik het nu heb gezien zal dit nieuwe MVC framework een stuk minder bagage met zich meenemen en krijgen we meer controle over de output en lifecycle. Deze aanpak spreekt mij wel aan.

[whoami]

Orphix schreef op woensdag 14 november 2007 @ 12:22:
Ik gebruik op dit moment al een MVC opzet in mijn ASP.NET applicaties. Echter is het wel een crime om dit goed te laten samenwerken met het WebForms model.

Hoe zet je dat MVC dan op in je ASP.NET app ?
Je maakt dan geen gebruik van Castle Monorail om dit te verwezenlijken ?

[Orphix]

whoami schreef op woensdag 14 november 2007 @ 12:24:
Hoe zet je dat MVC dan op in je ASP.NET app ?
Je maakt dan geen gebruik van Castle Monorail om dit te verwezenlijken ?

Mijn .aspx/.ascx en code-behind vormen samen de View. De pagina's en usercontrols implementeren een View interface. Deze interface wordt vervolgens gebruikt door de controller, wat een class is vanuit een class library project. Nu is het wel zo dat ik in de .aspx een instance van de Controller maak, de betreffende view-dependencies doe ik dan via de constructor van de Controller.

Wat nu lastig is, is bijvoorbeeld dat het gedrag van mijn controller afhankelijk is van instellingen in de Views. Wanneer een usercontrol of pagina bijvoorbeeld Viewstate uit heeft staan moet de data bij elke request weer worden opgehaald. Dit gebeurd via de controller. Wanneer de viewstate wel gebruikt wordt is dit niet nodig en hoeft de controller dit niet te doen.

Het idee dat je een controller hebt en een abstractie van je views (met als typisch voorbeeld een enkele controller en je views in asp.net WebForms en Windows Forms) gaat dus niet op. Aangezien de views invloed hebben op de implementatie van de controller.

Maar wellicht gebruik jij een andere definitie van MVC? Of een andere voorstelling hiervan? Ik ben namelijk niet bekend met Castle Monorail.

[whoami]

http://www.castleproject.org/monorail/index.html

Ik ga niet zeggen dat ik er echt bekend mee ben; ik ben gewoon van plan om -als ik de tijd vind- er even mee te spelen / me in te verdiepen.

[tijn]

EfBe schreef op woensdag 14 november 2007 @ 09:31:
[...]
1 ding vraag ik me wel af: hoe gaan ze 2-way databinding oplossen. Nu kan dat bijna zonder code (alleen maar HTML) met een slimme datasource control, maar met een controller waar de data naartoe moet eerst is dat IMHO lastig te doen. Op zich boeit databinding niet zo, IMHO, maar er zijn veel mensen waarvoor het een essentieel onderdeel is van hun werk.

Ik denk dat ze wel met een soort SmartDispatcherController gaan komen: http://castleproject.org/...rted/smartdispatcher.html

[mOrPhie]

Scott heeft het tweede deel van de serie geplaatst:

http://weblogs.asp.net/sc...k-part-2-url-routing.aspx

Dit stuk gaat over URL Routing. Dus het renderen van URL's en het mappen van die URL's aan controllers. Het klinkt nog redelijk flexibel. Ik was bang dat er maar 1 plek was waar je de routedefinities kon plaatsen, maar het blijkt dynamisch en (dus?) niet gefixeerd. Ik denk dat niemand het ziet zitten om alle routing via één aspx (global of niet) te laten gaan. De performance is namelijk van zowel je routetabel als het aantal controllers afhankelijk. Beide is een lookup. Ik denk dat de routetabel nooit erg groot zal zijn, maar het aantal controllers zou je misschien willen scheiden, of kraam ik nu complete onzin uit?

Ik vind het er persoonlijk wel goed uit zien. Het druist niet zo hard tegen de webprincipes in als dat webforms doet, maar tegelijkertijd krijg je de optie om server side controls te blijven gebruiken. Het is immers een kwestie van tijd voordat bijvoorbeeld de gridview MVC-ready is. Het is in elk geval goed een keuze te hebben.

[Crysania]

Ik zag toevallig ook deel 2 vandaag op scott's blog staan.

komend weekend kunnen we waarschijnlijk wat downloaden zodat we ook echt kunnen testen. Ik ga dat dan meteen doen.

[Crysania]

ter info:

deel 3 van de tutorial is door scott op z'n blog gezet:

http://weblogs.asp.net/sc...controllers-to-views.aspx

[flowerp]

EfBe schreef op vrijdag 19 oktober 2007 @ 09:41:
[...]
IS MVC wel DE manier om webpages te maken? MVC is niet een WEB pattern, maar een APPLICATION pattern.

Die eerste vraag is een vrij essentiële vraag en mijns inziens sterk gerelateerd aan de vraag of HTTP en HTML überhaupt wel geschikt zijn -applicaties- in te bouwen. Momenteel werk ik voornamelijk aan de andere kant van de heg met JSF (uit Java EE), wat als het goed is qua globale aanpak diverse overeenkomsten heeft met ASP.NET.

Voor het bouwen van web applicaties vind ik de MVC en component geörienteerde aanpak al wel een stuk beter werken dan het HTML met code eromheen gebeuren (ala JSP/PHP/ASP). Vergeet niet dat deze aanpak weliswaar uitstekend werkt voor kleine eenvoudige websites, maar hopeloos te kort schiet als je het echt over (enterprise) applicaties hebt. Toch blijft het behelpen. Ook in JSF moet je toch eigenlijk wel behoorlijk op de hoogte zijn van de lifecycle en de abstractie is nog zeker niet zodanig dat je compleet afgeschermd bent van het 'low-level' HTTP/HTML gebeuren.

Voor een groot gedeelte is het HTTP protocol daar zelf de schuld van. In essentie is het altijd een protocol gebleven om gewoon hypertext pagina's op te vragen (hence the name). Zoals EfBe al terecht opmerkt, sinds de prille begin dagen is er op dat niveau niet bijster veel veranderd.

Alle tig lagen die web frameworks erboven op leggen zijn alleen maar bedoeld om het geheel gewoon stateful te maken en om op steeds ingenieuzere wijze om tekortkomingen van het protocol heen te werken (b.v. de bekende problemen met de bookmark, de backbutton, het openen van 'conversaties' in meerdere vensters/tabs, het afsluiten van de browser tijdens een operatie, het vanuit de server updaten van diverse views, etc).

Sommige van deze lagen bovenop HTTP werken heel aardig, maar het blijft 'gedoe' en behelpen. Ik vraag me af waarom men in plaats van al die ontelbare uren in al die 1000'en frameworks en libraries niet eens gewoon het HTTP protocol kan gaan aanpassen zodat het beter aansluit bij het huidige gebruik ervan.

De meeste bovengenoemde problemen bestaan eenvoudig weg niet als je naar rich client side applicaties kijkt. MVC werkt daar dan ook veel beter en bovendien veel natuurlijker.

[Crysania]

de preview is uit btw: http://asp.net/downloads/3.5-extensions/

ik ga het vanavond even testen denk ik.

[Daspeed]

Ik hoop binnenkort ook ff een blikje te kunnen werpen. Van wat ik tot nu toe gezien heb word ik op zich best blij, al zitten er nog wel dingen bij waar ik nog wat vraagtekens bij heb (bijv. form handling/mapping naar objecten, validatie)

[mOrPhie]

flowerp schreef op zondag 09 december 2007 @ 21:02:
[...]


Die eerste vraag is een vrij essentiële vraag en mijns inziens sterk gerelateerd aan de vraag of HTTP en HTML überhaupt wel geschikt zijn -applicaties- in te bouwen. Momenteel werk ik voornamelijk aan de andere kant van de heg met JSF (uit Java EE), wat als het goed is qua globale aanpak diverse overeenkomsten heeft met ASP.NET.

Ik denk dat je het begrip "applicatie" teveel generaliseert. Veel websites zijn gewoon CRUD. Lichte interactie wordt opgelost in ajax en dhtml, maar echt heel spannend is dit vaak niet. Ajax-applicaties daargelaten (zoals google maps/docs enz). Echter, deze additie op asp.net richt zich niet op hevige interactie, maar op CRUD. Microsoft heeft niet voor niets Silverlight gemaakt. Ze weten dondersgoed dat de huidige webstandaarden niet afdoende zijn voor echte full-blown webapplicaties.

En als je puur CRUD kijkt, dan is HTML/HTTP prima. Je toont data, je verstuurt data. That's it. En dat is ook precies waar microsoft vaak de fout maakte. Ze probeerde HTML/HTTP in te zetten als een stateful-like omgeving. Mensen die zich daar niet van bewust waren en inderdaad gewoon bezig bleven met wat Webforms te bieden had, kwamen daardoor soms in de knoop met veels te grote viewstates.

Microsoft lijkt nu een beetje het licht te hebben gezien. Ze bieden een webframework voor CRUD en Silverlight voor interactie-rijke applicaties. Even los van of jij of ik het eens is met de Silverlight-aanpak; dat is een andere discussie. Ik denk dat op den duur Microsoft webforms laat voor wat het is en zich vooral zal richten op de nu ingeslagen weg.

[Daspeed]

Misschien ook wel interessant:
http://hammett.castleproject.org/?p=229

[kenneth]

En RC1 is uit.

Al mensen mee bezig geweest? Heb een beetje lopen kloten met de laatste beta, ik wilde met de RC1 een site (voor intern gebruik) bouwen om serieus te kijken of het wat is. Matiger dan Webforms kan het niet zijn

[Daspeed]

kenneth schreef op woensdag 28 januari 2009 @ 13:27:
En RC1 is uit.

Al mensen mee bezig geweest? Heb een beetje lopen kloten met de laatste beta, ik wilde met de RC1 een site (voor intern gebruik) bouwen om serieus te kijken of het wat is.

Ik denk dat ik komend weekend maar eens een poging ga wagen (ik ga er vanuit dat nu de API niet al te drastisch meer gaat wijzigen).

Ik hoop alleen dat ze niet al te veel backgroundmagic hebben toegepast, waardoor het lastig wordt om dingen op te lossen op een niet-MS-standaard manier (andere viewengine, helpers, etc)

Matiger dan Webforms kan het niet zijn

Dat klopt

[Snake]

Ik vind het heel fijn werken, vooral als je van het Zend Engine afkomt, dan is de overstap heel snel gemaakt

Ik heb wel ergens gelezen dat je geen viewstate meer hebt, maar ik heb geen idee wat een viewstate is

[Daspeed]

Viewstate heeft te maken met het Webforms framework en is simpel gezegd een hidden input field in je html form met daarin encoded gegevens over je formulier (welke controls, de data van die controls, etc).

Viewstate heeft alleen nogal de neiging om iets te worden waaraan je jezelf kan ophangen

[Snake]

Daspeed schreef op woensdag 28 januari 2009 @ 22:08:
Viewstate heeft te maken met het Webforms framework en is simpel gezegd een hidden input field in je html form met daarin encoded gegevens over je formulier (welke controls, de data van die controls, etc).

Viewstate heeft alleen nogal de neiging om iets te worden waaraan je jezelf kan ophangen

Dus het is goed dat ik een website kan bouwen zonder die viewstate?

[kenneth]

Zalig zij die Viewstate niet kennen.

Maar, mocht je het toch willen weten: dit is een goeie uitleg.

[Orphix]

Ik werk al een tijdje met ASP.NET MVC en het is een waar genot, vergeleken met de webforms manier. Zoals wel vaker met alle RAD omgevingen werkt het tot op een bepaald punt en niet verder, en daar loop je bij webforms al snel tegenaan. ASP.NET MVC geeft je de flexibiliteit om overal in te grijpen (als je wilt) en die controle is erg fijn. Als het aan mij ligt ga ik nooit meer terug (ben gelukkig ook geen maintenance programmeur )
En hoewel de API tussentijds best wel is veranderd is het al vanaf de eerste previews een stabiel product geweest, het is zeker aan te raden om daar al sites mee te gaan ontwikkelen.

[D4Skunk]

Orphix schreef op donderdag 29 januari 2009 @ 00:59:
Ik werk al een tijdje met ASP.NET MVC en het is een waar genot, vergeleken met de webforms manier. Zoals wel vaker met alle RAD omgevingen werkt het tot op een bepaald punt en niet verder, en daar loop je bij webforms al snel tegenaan. ASP.NET MVC geeft je de flexibiliteit om overal in te grijpen (als je wilt) en die controle is erg fijn. Als het aan mij ligt ga ik nooit meer terug (ben gelukkig ook geen maintenance programmeur )
En hoewel de API tussentijds best wel is veranderd is het al vanaf de eerste previews een stabiel product geweest, het is zeker aan te raden om daar al sites mee te gaan ontwikkelen.

* D4Skunk is met hem...
Ik gebruik het ook al sinds de beta, en ben er effectief een produkt voor een klant mee aan het ontwikkelen. Na zelf x tooltjes en een hele lib geschreven te hebben om asp.net een beetje deftig te laten samenwerken met een MVP-app-pattern heb ik gewoon de hele boel gedumpt, en ben ik begonnen in asp.net MVC, en ik moet eerlijk zeggen : wat een verademing !!!
De routes zijn een joy, de actionhandlers zorgen ervoor dat je zowat alles kan doen wat nodig is, en het hele jQuery-gebeuren zorgt er voor dat ajax etc een piece-of-cake wordt (zeker als je plugins gebruikt zoals jEditable).

Ik heb een tijdje geleden geprobeerd om RoR te verkopen aan klanten, maar dit was geen succes... (Non-MS is niet zo eenvoudig te verkopen).
Gelukkig hebben we nu asp.net MVC, wat zorgt voor min-of meer dezelfde flexibiliteit, maar dan wel door MS aangeleverd.
Zelf gebruik ik trouwens wel nog steeds een aparte lib/dll voor mijn service- & repository-layer, en heb ik nog steeds x helper-functietjes om mijn leven te vereenvoudigen.
Als ik er nu nog in slaag om mijn IRepository<T> te laten werken met fluent-nhibernate, en vervolgens automatisch mijn db schema te genereren icm sqllite of iets dergelijks, dan ben ik de koning te rijk....

in elk geval: 2 thumbs up voor ASP.NET MVC !!!

[Verwijderd]

/me is ook bezig met ASP.NET MVC. Maar ik ben ook wel benieuwd naar RoR.

Die controllers zijn erg fijn. Zeker ook omdat je nu fatsoenlijk met HTTP POST/GET kan werken. En met JQuery Controllers aanroepen is ook vet!

[Verwijderd]

ASP.NET staat erg hoog op de to-do list voor de komende weken! Ik ben geen superfan van web programming, maar moet natuurlijk wel een beetje bijblijven
Heb gelukkig ook nog wat fijne ideeen die ik uit wil werken

[D-Raven]

ASP.Net MVC Na 3 jaar lang afzien eindelijk verlichting. Waar ik werk gaan ze ook volledig overstappen naar MVC. Dit wordt een consolidatie project van ASP, ASP.Net, en Monorail naar MVC. Kan niet wachten

[meraki]

ASP.NET MVC 1.0 werd gisteren gereleased, iemand 'em al uitgeprobeerd?

Vraag: Ik ben van plan om een Restful webservice te bouwen, is ASP.NET MVC hiervoor een alternatief t.o.v. WCF?

[ Voor 5% gewijzigd door meraki op 19-03-2009 10:26 ]

[whoami]

Eh, ASP.NET & WCF zijn eventjes 2 heel verschillende dingen ...

[meraki]

whoami schreef op donderdag 19 maart 2009 @ 09:26:
Eh, ASP.NET & WCF zijn eventjes 2 heel verschillende dingen ...

Akkoord, ik refereerde naar het bouwen van RESTful webservices. WCF heeft hiervoor ingebouwde ondersteuning maar aangezien MVC de nadruk legt op controle v/d URL/URI lijkt me het niet zo onlogisch dat MVC hiervoor ook geschikt zou kunnen zijn?

[YopY]

Ik heb geen ervaring met ASP.NET MVC, maar heb er recent een soort van onderzoek naar gedaan, evenals naar andere (meestal MVC) frameworks.

Voor zover ik kon bekijken is ASP.NET MVC Meer Van Hetzelfde - het biedt een redelijk standaard implementatie van MVC aan, zonder veel vernieuwende functionaliteit of nieuwe ideeën. Mijn min-of-meer conclusie in het verslag was dan ook dat ASP.NET MVC eigelijk alleen een goede keuze is wanneer Microsoft eigenlijk de enige mogelijkheid is, bijvoorbeeld door eisen van de klant of omgeving, of de ervaring van de ontwikkelaars.

Dat neemt natuurlijk niet weg dat MVC een goede toevoeging is op de toch al imposante .NET bibliotheek - zeker in combinatie daarmee kan het nog zeer groot worden.

Microsoft is trouwens wel wat laat op de MVC boot gesprongen, vind ik.

[kenneth]

Wat ik al verbazingwekkend genoeg vind is dat het best bruikbaar is voor een 1.0 ... meestal moet je bij MSFT op een 2.0 wachten voor je het product ook daadwerkelijk wil gebruiken.