Een tijdje geleden heb ik op een project gewerkt met SVN voor source control.
Meestal werk je als Microsoft developer met VSS (Visual Source Safe) of TFS (Team Foundation Server) maar voor een klein project was ik best gecharmeerd geraakt van SVN tezamen met Tortoise  als client tool.

Vooral het principe dat er geen bestanden read-only worden gemarkeerd en je lekker kunt editen, ook off-line, vond ik erg ok.
Waar ik echter tegenop zag was het installeren van een SVN server; de how-to pagina’s waren niet altijd even consistent en helder.
Maar wat is er nu (of misschien al langer, maar voor mij is het er nu): Visual SVN.

Een Next, Next, Finish installatie van SVN.
Geprobeerd, en het werkt. Dus ook voor kleinere projecten of 1-mans projecten waar je source control wilt gebruiken (al is het alleen maar om een dolgedraaide designer te kunnen rollbacken) een mooie oplossing.

Hij was er, wel een van de meest bekende mensen en sprekers van- en over .Net: Scott Guthrie.
Verantwoordelijk voor een groot deel van .Net, webforms en het verhaal gaat dat hij de grote lijnen van ASP.Net MVC in een vliegtuig in elkaar heeft getimmerd.
Hij was in Engeland en Nederland, en de vrienden van DotNed hebben het voor mekaar gekregen om hem als spreker te boeken. Afas was zo vriendelijk de sessie te hosten, en het was in 1 woord geweldig.
Wat een ervaring, wat een enthousiasme, wat een drive, wat eigenlijk niet?
Daar staat dus een van de grote mensen van Microsoft voor 250 man in Nederland te vertellen over ASP.Net MVC en over Visual Studio 2010. En dan niet een standaard sales praatje of een schrale demo, maar twee keer 2 1/2 uur praten. En hoe! vol enthousiasme en plezier vertelt hij de dingen alsof hij ze pas net heeft ontdekt.
Een genot om deze man mee te maken, veel wijzer geworden en een leuke avond gehad.

Deel 2 over de ervaringen met het ASP.NET MVC framework

Testbaarheid
Veel genoemd als voordeel en dat is zeker terecht: de testbaarheid.
Omdat de (business logica) rol van de view heel klein is ligt alle logica bij de controller of anders gezegd: als je de controller van de juiste data voorziet en de juiste actie aanroept, dan zal deze de juiste data teruggeven en ook de juiste view aanroepen. Dat is natuurlijk mooi te testen: wat een pagina uit je site doet, namelijk het posten van data (via FormPost of Get) naar een actie van een controller, kun je vanuit je testproject ook. Je hebt dus geen last van allerlei verborgen acties die nog in je view worden uitgevoerd. Een plus voor testen. 

Viewstate
Geen viewstate. Omdat we geen server controls hebben die allerlei state met zich mee dragen hebben we ook geen viewstate. Uitzetten kan in een gewone ASP.NET applicatie natuurlijk ook, maar de wat intelligentere server controls zoals de GridView vinden dat geen goed idee: het event model houdt er dan ook mee op. En geen view state geeft toch al gauw een fikse page size verbetering. Een plus voor filesize.

Bewuster van htmlcode
Een indirect voordeel van het werken met het ASP.NET MVC framework is dat je je veel bewuster bent van de html die je site oplevert. Van een GridView weet eigenlijk niemand wat voor html deze oplevert, en in het geval van een server control is dat ook eigenlijk niet belangrijk. Maar als je je wel van de html bewust wilt zijn, bijvoorbeeld omdat search engine optimalisatie belangrijk is, dan is dat met het MVC framework sneller het geval.

Microsoft’s versie 1.
Het verhaal gaat dat een versie 1 product van Microsoft eigenlijk niet productierijp is. In dit geval is dat in ieder geval niet zo. We hebben vanaf dag één productie kunnen draaien.

Overzicht aspx
Bij een gewone ASP.NET site staat veel code in de code behind file. Ook wordt daar veel opmaak werk gedaan, controls aangemaakt etc.
Met het ASP.NET MVC framework doe je dat allemaal in de view (de aspx / ascx files). Dat geeft soms wel een wat onoverzichtelijke pagina: het wordt al snel een mengelmoes van html tags en for-each loops die door de data heenlopen die de controller aan de view heeft gegeven. Een min voor overzichtelijkheid van de view.

Leercurve
Een nadeel om er mee aan de slag te gaan is zoals altijd de leercurve. Deze is bij dit framework best aanwezig, want het is niet iets dat je half kunt implementeren en het is ook niet iets dat er even naast hangt: het vervangt een redelijk deel van de ASP.NET kennis die je hebt; o.a. die van de vele server controls die ASP.NET rijk is. Zelf heb ik het boek van o.a. ScottGu gelezen (Professional ASP.NET MVC 1.0) en daarmee heb je de basis in ieder geval snel onder de knie. Een min als je morgen direct moet beginnen. 

Geen server controls
In het begin vraag je je af: waar begin ik aan. Al dat extra werk dat een server control je uit handen neemt. Maar aan de andere kant: het is ook wel vaak gedoe met die controls. Een GridView lijkt heel handig, helemaal als je de voorbeelden ziet met inline editen van data. Maar als je zelf aan de gang gaat, zonder de gesleepte SqlDataSource maar gebruik makend van je DAL, dan moet je vaak toch wel flink wat tweaken. En code als de ItemDataBound, de FindControl, de (Cells[0].Controls[0] as TextBox).Text etc. zijn ook niet altijd even handig. Conclusie: het viel eigenlijk best mee om zonder deze controls aan de gang te gaan. Een GridView is met een foreach loop ook zo opgebouwd, en als je de flow van je site in je hoofd hebt zijn de edit, delete en insert buttons ook zo gemaakt.

Geen abstractie
Het ASP.NET framework biedt een heleboel abstractie aan. De acties binnen een website zijn eigenlijk heel simpel: je doet vanuit de client een GET of een POST, en op de server kijk je welke data er mee is gekomen (via de Form data of de querystring) en afhankelijk van de pagina die wordt geladen en de data die je hebt meegekregen voer je je actie uit en bouw je een nieuwe pagina op.
De hele abstractielaag die ASP.Net daar op heeft gebouwd zoals de Postback, de button_click events als ware het een Windows applicatie, de events die op server controls afgaan: als je de overstap maakte van een windows applicatie leek het zo heel logisch, maar soms maakt de abstractie het moeilijker dan het origineel was. Van een simpele Post wordt een form_load gemaakt met een IsPostback property, een Button_click, een aantal events op een GridView, een findcontrol op de pagina, een OnChange event van een textbox, een databind() van een Repeater en wat al niet meer. Jarenlang een gegeven, maar nu met de ervaring van het MVC framework valt het wel op dat het niet alleen maar simpeler is, zo’n abstractielaag. Een plus voor de overzichtelijkheid van het ASP.NET MVC framework.

Conclusie
Conclusie is dat ik het ASP.NET MVC framework een dikke pluim geef en het volgende keer zeker weer zou inzetten bij een dergelijk project.

‘k heb net een groot project afgerond dat is gebouwd met het ASP.NET MVC framework.
Het betrof hier de herbouw van www.beurs.nl, een site waar performance een must is, SEO ook, en runtime errors en work-arounds zijn niet welkom. Oftewel: een mooie testcase voor dit nieuwe framework.

In deze post als eerste: wat is het ASP.NET MVC framework (vanaf hier genoemd: MVC)?
MVC is een pattern dat al lang bestaat en de opbouw van je applicatie opdeelt in de componenten Model, View en Controller. Hierbij komt een aanvraag of request van in dit geval een webpagina binnen bij de controller. Meestal komt er ook nog data mee in de aanvraag: bij een Get request zit dit in de querystring (www.beurs.nl/zoek/term=AEX) en bij een Post request zit het in een aparte collectie met data en bevat het de inhoud van de velden van je Form.

Het verschil met de gewone aspx pagina is dat nu niet een Page object wordt opgestart (met normaal het eerste contact in de form load, die kijkt of het een postback is etc etc) maar een Class die afgeleid is van een MVC Controller object.
Dit is direct het eerste verschil: je komt nu binnen in een apart object (de controller), terwijl je anders in een code behind van een grafisch element, een form, binnenkomt.
Deze controller (de C uit het MVC) heeft meerdere Actions in zich, die je implementeert als methode in het Controller object. Deze Actions kunnen bijvoorbeeld zijn: SaveNews, PostComment, CreateRssFeed, EditNews etc. De koppeling tussen url’s en de controller/action combinatie doe je in de Global.asax, daar zet je in dat ‘/nieuws/binnenland/AEX stijgt’ naar de controller ‘News’ moet, en naar de Action (methode) ‘news’ en dat deze een parameter van het type string heeft waar dan de tekst ‘AEX stijgt’ in wordt geplaatst.

Je voelt nu al dat dit wel gemakkelijk testbaar is, want een methode aanroepen met een parameter is iets dat je nu ook al doet in test projecten.
De Action heeft dan de kennis in zich wat hij moet doen. In dit geval moet hij de cache controleren, eventueel het nieuws uit de database halen en het toevoegen aan de cache. Deze laatste acties, het al dan niet gecached ophalen van de data, zit in je service- en datalaag. Deze twee lagen samen vormen je Model (de M uit het MVC). Je kunt het Model dus ook wel zien als je business layer gecombineerd met je data layer.

Als de controller deze data heeft opgehaald dan bepaalt hij welke view (de V uit het MVC) deze data moet gaan tonen: is de data bestemd voor een nieuwsfeed of voor een usercontrol of voor een HTML pagina of iets anders. Meestal zal het laatste het geval zijn en geeft de controller de opgehaalde data aan de View. De view ten slotte heeft de kennis in zich hoe een en ander op het scherm getoond gaat worden; welke data in welke DIV geplaatst wordt, en afhankelijk van de data welke css style erop van toepassing is. Standaard is de view een ASPX pagina die niet afleidt van het Page object maar van de Mvc.ViewPage.

De verschillen tussen een gewoon webproject en een MVC project die het meeste in het oog springen:

• Geen Viewstate
• weinig tot geen SessionState
• Eenvoudig SEO-friendly url’s
• Geen servercontrols (DataGrid, ObjectDataSource)
• Wel volledige controle over de gegenereerde HTML
• Goede testbaarheid
• Geen code behind
• Duidelijke separation of concerns

In de volgende post: de ervaringen met het ASP.NET MVC framework.

Er is een onderzoek geweest dat sites met veel afbeeldingen (en daarbij tellen zeker ook achtergronden van buttons en hun mouseovers) een groot deel van de laadtijd besteden aan het 1 voor 1 laden van die afbeeldingen.
De browser haalt namelijk de html op, en komt er dan in de CSS (background: url(‘mouse.gif’) no-repeat;) of de HTML zoals de image source (<img src=”mouse.gif”) achter dat er nog een plaatje van de server afgehaald moet worden.
Bij veel afbeeldingen loopt dat aantal requests snel op, en dat geeft wel een ervaring aan de gebruiker dat er iets aan het gebeuren is, maar kan al met al wel tot 50% van de laadtijd extra kosten.
Vroeger (in internet termen dan) was het wel een must om de gebruiker te laten zien dat de pagina iets aan het doen is, maar aangezien de meeste 28K8 modems er wel zo’n beetje uit zijn, kun je ook het volgende doen:
Je neemt in plaats van allemaal kleine afbeeldingen 1 grote afbeelding, en je laat alleen dat stukje van de afbeelding zien wat je op dat moment nodig hebt.
Als je de eerste aanroep van de afbeelding bovenin je html zet, dan zijn in de rest van de pagina alle afbeeldingen al direct, zonder nieuw request, beschikbaar.

Vandaag was het weer zover, de Microsoft DevDays 2009.

Een bijna vertrouwd gezicht om Arie Leeuwesteijn de opening te zien verzorgen.

Dit jaar een best interessante keynote; niet alleen amusant maar ook informatief over The Azure Services Platform.

Daarna een hele goede presentatie van Ingo Rammer over Dynamic Data. Dynamic data is een te customizen ‘applicatie’ die voor een of meerdere tabellen in je Entity Framework een CRUD site genereert. Het genereren gebeurt runtime aan de hand van templates en je Model, dat grotendeels uit het EF komt maar waar je zelf ook aanpassingen aan kan doen. Je kunt bv van een attribuut aangeven dat het een waarde mag hebben tussen 0 en 100 en er wordt dan bij een refresh van je pagina direct een validator gegenereerd.
Mooi spul, zeker voor een admin tool of een klant die de afweging maakt van een minder tailor made applicatie tegen een lagere kostprijs. Na MS-Access is er eindelijk weer een eenvoudige datadriven oplossing van Microsoft.

Daarna een vrij technische verhandeling over production debugging. Leuk om te zien wat er allemaal mogelijk is aan monitoring, memory dumps, managed- en unmanaged memory e.d. Een leuk stukje: midden in het verhaal was er ineens een heap dump te zien met daarin o.a. een OutOfMemoryException. Het bleek dat je die niet serieus moest nemen in je diagnose omdat die er altijd in zit: als de CLR start dan wordt deze al op de heap geplaatst omdat als de CLR echt een out of memory tegenkomt, hij geen geheugen meer vrij heeft om een OutOfMemoryException op de heap te plaatsen.

Vervolgens een presentatie over ASP.Net Ajax 4.0 die nu in Beta was (of in CTP, ‘k weet niet zeker). Het kwam er eigenlijk in het kort op neer dat ze een hele grote Ajax library aan het bouwen zijn waarmee je in de client op dezelfde manier, dus niet met C# zoals in Silverlight, maar op een gelijke wijze dingen moet kunnen doen als op de server.

Het slot was van Sander Hoogendoorn met een mooie presentatie* over frameworks die niet alleen aan het einde wel trek had in een biertje (wat er overigens niet was zover ik kon zien) maar ook twee mooie uitspraken had:
Over een passend formaat framework: “Frameworks zijn er, net als pizza’s, in 2 formaten: te groot en te klein.“
en over de lock-in die een framework vaak met zich mee brengt: “Frameworks zijn net als vrouwen, je kunt er niet mee leven en je kunt ze niet killen“.

Al met al een amusante dag: veel gezien en gehoord, nog wat leuke boeken gescoord en oud(e) collega’s ontmoet.

* Bij Sander spreek je eigenlijk niet echt over een presentatie maar meer over een infotainment show

Ik had een mooie copy-paste actie, die helaas tot een niet te reproduceren fout leidde.
Het begon allemaal met een Ajax sectie in een MVC partial view:

<%
using (Ajax.BeginForm(“AddComment”, “Comment”, null, new AjaxOptions

  Toen wilde ik ergens anders een Ajax link maken. Ok, het is iets heel anders, maar ook daar wilde ik een set AjaxOptions meegeven. Dus… copy-paste.
Wel het LoadingElementId element weggehaald, maar de 2 events laten staan voor debug doeleinden met een alert erbij.
Maar toen de link werd uitgevoerd en de controller een partial view retourneerde, werd deze niet, zoals het hoort, netjes in de pagina verwerkt, maar kreeg ik alleen de partial view te zien, in plaats van de hele pagina.
Wat bleek de crux te zijn: de 2 OnXXX events horen natuurlijk helemaal niet bij een Link, en niet alleen horen ze er niet bij, maar als je ze er wel bij doet, dan krijg je genoemd gedrag.

Ik moet zeggen, toen ik 2 jaar geleden voor het eerst een boek over Linq las en daar een heel stuk stond over Lambda expressions, dat ik halverwege wel even achter m’n oren moest krabben: wat is dat voor iets?
Maar zoals met alles, als je het meer en meer ziet ga je zelf ook wat proberen en gebruik ik nu de volgende 2 lambda’s regelmatig.
De ene is voor het selecteren van objecten uit een generic List op basis van een property van dat object, de andere is voor het ophalen van een lijst met de waardes van 1 property van die objecten (deze staat verderop in de blog ook al vermeld, maar voor de compleetheid toch nog even vermeld).

De case bij de eerste is: ik heb een lijst met keyword objecten. Deze hebben allemaal een property ‘rank’. Nu wil ik een lijst met alleen die keywords die minimaal een rankwaarde van 2 hebben. Daarvoor gebruikte ik altijd een mooie anonymous delegate die ik van m’n vriend en oud-collega René had geleerd (en het stond altijd wel biek, een anonymous delegate ) :
keywords.FindAll(delegate(Keyword m) { return m.Rank >= 2; });
Met een Lambda wordt het echter dit:
keywords.FindAll(m => m.Rank >= 2)
En dat is toch ook wel mooie code vind ik.

De case bij de 2e is: ik heb nog steeds die lijst met keyword objecten. Deze hebben naast de genoemde rank ook een value. En dat is waar ik op dit moment interesse in heb: in al die values. Ik heb dus een lijst met keyword objecten, en ik wil graag een lijst met strings gevuld hebben.
De oplossing zit in de ConvertAll methode:
List<string> values = keywords.ConvertAll(z => z.Value);

ps.
ik heb nog even opgezocht wat Microsoft eigenlijk zegt over een lambda expression:
A lambda expression is an anonymous function that can contain expressions and statements, and can be used to create delegates or expression tree types.

Als je net begint met het Asp.Net MVC heb je waarschijnlijk veel zaken waar je tegen aan loopt, maar 1 van de eerste is waarschijnlijk de routes: je definieert in je global.asax je routes, je opent de browser en…. daar is je view niet.
Vooral als je veel routes hebt gedefinieerd is het soms moeilijk in te schatten welke paden worden doorlopen en welke niet.
De oplossing is simpel gelukkig: een DLL toevoegen aan je project en 1 regel code aan je global.asax, en dan zie je dit:

Je ziet een lijst met alle routes die je hebt ingegeven, en in het groen de routes die matchen met de url die je op dat moment in hebt gegeven.
Daarnaast zie je bovenin in de kleine tabel welke controller er wordt aangesproken, wel action er wordt uitgevoerd en de waardes van de eventuele parameters.

Hear hear:  http://haacked.com/archive/2008/03/13/url-routing-debugger.aspx

Zo, dat is een hele zin…

Maar goed: stel je wilt in je site die lekker Ajax dingen doet even luisteren naar het HTTP verkeer. Je gebruikt Fiddler (in mijn geval v.2.2.2.0) en je hoort op htpp://localhost:47867/ …. niets.
De standaard oplossing is een punt (.) tussen de localhost en de dubbele punt. Dan krijg je
htpp://localhost.:47867/
Dat werkt alleen niet echt onder Vista. Niet geprobeerd maar gelezen is oplossing 2: geen localhost gebruiken maar je machinenaam. Dan krijg je
http://mydevmachine.:47867/ maar dat schijnt het niet goed te doen bij de interne webserver van Visual Studio.
De laatste mogelijkheid, en die deed het ook bij mij, was het localhost ip adres; en dan krijg je http://127.0.0.1.:47867/

En dan ziet Fiddler alles voorbij komen!