Donderdag is MartinS op mijn pas geweet en vrijdag was het dan eindelijk mijn beurt om een bezoekje te plegen aan de DevDays van dit jaar. De eerste sessie die ik op het programma had staan was van Alex Thissen over het ASP.NET MVC Framework. MVC staat voor Model-View-Controller en is een interessant design pattern waar Microsoft dus een eigen Framework voor aan het bouwen is. Dit Framework is nog niet af en kan in details nog wel veranderen, maar je kon er een goede indruk van krijgen. Omdat ik verkeerd was gelopen en aan de andere kant van de RAI bij een andere sessie uitkwam, kon ik geen plaatsje meer veroveren en moest ik de hele sessie staan. Mede daarom heb ik ook geen aantekeningen gemaakt.

Als je gebruik maakt het MVC Framework, gooi je een hele hoop functionaliteit de deur uit en kun je niet meer vertrouwen op de Page Lifecycle; Page_Load en andere (postback) events zul je niet meer op de normale manier gebruiken; veel Server Controls werken niet. Een request komt binnen op de Controller, die bepaalt wat er precies gevraagd wordt en zorgt dat de juiste gegevens worden uitgewisseld met het Model om vervolgens de juiste View (pagina/aspx) op te starten en gegevens aan mee te geven. Een Request gebeurt wel met een mooie url in de zin van: www.mijnwebsite.nl/Artikel/Edit/67. Deze ‘routes’ zijn helemaal te configureren met standaard waarden voor elk onderdeel uit de url en wat al niet meer, nu nog in de global.asax, maar wellicht straks ook in de Web.config. Wat wel een grote drempel voor mij en vele andere ASP.NET ontwikkelaars zal zijn, is dat de View (de aspx) erg veel gaat lijken op oude asp. Je ‘for loopjes’ komen tussen de html te staan en je maakt zelf je html op; wel zijn er veel hulpfuncties om html te genereren voor bijvoorbeeld dropdowns en textboxen, maar het wordt toch weer de ouderwetse wirwar van code en html. Een van de grootste voordelen die altijd worden genoemd, is dat dit design pattern de testbaarheid van je presentatielaag velen malen groter maakt en het wordt dan vaak ook aangehaald in combinatie met TDD (Test Driven Development), hoewel daar ook wel Model-View-Presenter voor wordt gebruikt, een iets andere variatie op MVC. Om dit te benadrukken wordt een MVC project in Visual Studio altijd automatisch voorzien van een testproject.

De vraag blijft staan of dit Framework toegepast moet/kan worden in toekomstige projecten of niet. Sommige projecten zijn minder geschikt dan andere en er zal een grote omschakeling moeten komen van de ontwikkelaars. Wat de keuze nog moeilijker maakt, is dat het design pattern zo cool is en dat het heel goed bijdraagt aan ‘Seperation of Concerns’, dus het scheiden van code met elk een ander doel in de applicatie.

De tweede sessie had als titel ‘Is LINQ your Data Access Layer’ en werd gepresenteerd door Anko Duizer. Wederom was ik te laat voor een stoel, maar hier kon je redelijk relaxed achteraan op de grond hangen en toch nog wat volgen. Twee stellingen werden er voorgelegd: LINQ to SQL is de DAL en LINQ to SQL wordt gebruikt in de DAL.

Als LINQ to SQL (vanaf nu gewoon LINQ voor het gemak) de DAL is, dan zal eventuele business logica ook in deze laag moeten zitten en is het dus eigenlijk twee lagen in één. Voordelen zijn o.a. simpel en snel om te gebruiken, dus goed voor RAD, binding is heel goed geregeld. Nadelen zijn o.a. dat er nagenoeg een 1 op 1 mapping is tussen Relationele DB structuur en Object structuur in code en dat je dus een mix krijgt van Presentatie, Business en Data Access. De uitbreidingen die je maakt (business logica) zijn wel mooi weg te stoppen in Partial Classes/Methods. Van 1 tabel met een soort Type-veld is het mogelijk om obv dat veld onderscheid te maken en er een base-class van te maken met meer dan één afgeleide classes (BaseUser -> Author en Publisher).

Als LINQ wordt gebruikt in de DAL zul je een betere scheiding kunnen realiseren, maar is er ook veel meer werk nodig. Voordelen zijn o.a. dat je een echte DAL hebt, dat je een betere mapping hebt naar je eigen Domain Model (Business Entiteiten / Information Packages), dat het mogelijk is om nog te switchen naar andere techniek, omdat het een eigen laag is. Nadelen zijn o.a. dat er veel meer code nodig is en dus veel meer tijd zal kosten; bovendien moet er veel meer nagedacht worden over bepaalde obstakels die je zal tegenkomen. Omdat alles in een DataContext zit opgesloten is het lastig om de objecten naar de Presentatielaag te serialiseren en weer terug te deserialiseren. Hier zijn 3 methoden voor: LNQ to SQL Entities (de meest simpele), POCO’s (Plain Old CLR Objects, meeste werk, maar ook meest clean door gebruik van eigen Domain Model / Information Packages) en DataSets (veel support, maar ook beperkingen). Normaal wordt gebruik gemaakt van Deferred Loading, wat inhoud dat er pas iets uit de DB wordt gehaald op het moment dat je het in je code (in een loop bijvoorbeeld) nodig hebt. Dat is na serialisatie naar de Presentatielaag natuurlijk niet meer mogelijk, dus je moet van te voren bepalen wat je nodig hebt: heb je bijvoorbeeld alleen de Orders nodig of wil je ook alle Orderregels erbij hebben?

Algemeen zijn er nog wat opmerkingen te maken. LINQ to SQL is standaard optimistisch qua concurrency, wat inhoudt dat je zelf conflicten moet afhandelen als Dirty Reads e.d. Het is mogelijk om een cache mismatch te krijgen, doordat de DataContext los van de database staat. Een gebruiker zal dan vreemde resultaten te zien krijgen.

Het antwoord op de vraag die in de titel van de sessie wordt genoemd, is niet anders te beantwoorden dan met iets als: “Het kan, maar het hangt ervan af.” Als je je eigen Domain Model wilt behouden, dan moet je het gebruiken in je DAL en kan het niet de DAL zijn. Wat je je dan wel goed moet afvragen, is of LINQ to SQL je dan voordeel oplevert t.o.v. gewoon ADO.NET. In mijn eigen beleving is dit niet het geval, zeker niet als je je bedenkt dat we al een hele opzet hebben voor een DAL. Het voordeel van LINQ to SQL zou dan vooral zijn dat er heel veel wordt gegenereerd en je dus minder (steeds weer dezelfde) code hoeft te schrijven.

Na de lunch stond “Understanding ADO.NET Data Services” op het programma. Dit gaat over een tegenhanger van Web Services en worden ook wel RESTful Services genoemd. Data Services gaat volledig over http en maakt gebruik van het pure http-protocol. Het is dus geen SOAP. WCF kan onderliggend gebruikmaken van REST en van SOAP, dus je blijft de keuze houden; Microsoft gooit SOAP niet weg na zoveel investeringen.

Elk soort data kan gebruikt worden over deze Data Services. Ophalen van gegevens is eenvoudig, maar voor een update moet er veel moeite gedaan worden. In het toekomstige Entity Framework zal een ObjectContext beschikbaar zijn; als je daarvan gebruik maakt is ook het updaten weer eenvoudig geworden.

Wat erg mooi is, is dat je je volledige datasource al kan zien/testen via de url van je browser. Je krijgt dan alles wat je opvraagt (inclusief query-achitge zaken als top, startpositie, filter etc.) in XML. Ook in de code is het erg makkelijk om een query te schrijven tegen een Data Service; dit is zelfs mogelijk met LINQ: de LINQ query wordt dan vertaald naar een Data Service query. En wat ook erg handig en makkelijk is, is dat dit ook erg eenvoudig vanuit Javascript is te doen, dus voor AJAX.

De vierde sessie was moeilijk te kiezen, want eigenlijk spraken de titels me allemaal niet aan. Ik heb gekozen voor Parallel Extensions to the .NET Framework, gepresenteerd door een echt grappige kerel: Daniel Moth. Deze Extensions zijn nog in de maak en er is nu pas een eerste openlijke beta/ctp uit; het enige wat zeker is, is dat het niet dit jaar uitkomt. Ook zullen wij er als Web Developers niet veel mee te maken krijgen. In het begin stonden er quotes op het scherm die we konden lezen; wel interessant wat men denkt over de toekomst van normale desktops pc’s: meer Hz is niet goed meer te doen door de beperkingen in koeling van de chips; in de laatste twee jaar zijn we daardoor heel snel al naar Quad cores gegaan voor de normale consument. Volgens de wet van Moore verwachten ze dat we binnen tien jaar al mainstream pc’s hebben met 80 cores (dat hoeft niet perse 1 cpu te zijn natuurlijk). Het is daarom belangrijk om je te richten op het efficiënt gebruiken van de cores. De Parallel Extensions moeten dat makkelijker gaan maken. Het biedt een laag niveau API dat je niet hoeft te gebruiken, maar wel beschikbaar is en twee meer bruikbare/simpele API’s die daarop gebouwd zijn. De ene is slimmer dan de Thread Pool class, maar minstens zo uitgebreid en bruikbaar als de Thread class, de tweede is een uitbreiding op LINQ en kan LINQ query’s heel makkelijk uitbreiden voor multiple cores.

De laatste sessie was: “Leveraging C#3.0 and LINQ (Best Practice)”, en beetje saai en de spreker probeerde grappig te zijn, maar was het niet. Misschien lag het ook deels aan mijzelf, maar ik kon mijn gedachten er niet goed bijhouden. Toch heb ik nog wel een paar dingen genoteerd. Voor de rest kun je bij JanV zijn, want die heeft deze sessie ook gevolgd.

Met Partial Classes kun je goed uitbreiden. Wil je in LINQ op een mooie manier n op m relaties leggen (dus relaties die een koppeltabel nodig hebben), dan kun je zelf een property maken in de ene class die een List van e andere teruggeeft. De getter van de property loopt dan door de ‘koppeltabel’ heen om de juiste items terg te geven. Het is ook mogelijk om met een extra property enkele properties samen te voegen in 1 nieuwe property van een eigen type. Als je bijvoorbeeld adresgegevens los hebt staan in een tabel, dan kun je deze private maken in LINQ. Vervolgens kun je een Adres-Class maken en een nieuwe property van het type Adres. In het adres geef je dan de afzonderlijke (private) adresgegevens terug.

In LINQ is paging standaard ingebouwd! Je doet in een LINQ query gewoon heel gemakkelijk “.skip(x).take(y)” om x items te skippen en vervolgens y items op te halen. LINQ zal er dan zelf voor zorgen dat de meest optimale query wordt uitgevoerd. In SQL2005 zal dit vaak met ROW_NUMER() zijn (behalve op de eerste pagina (optimaal dus)) en in SQL 2000 zal de query een stuk ingewikkelder zijn. Het mooie is dus dat je daar zelf niets meer mee te maken hebt.

Al met al was het dus een interessante dag. Ik vond het minder dan vorig jaar, maar misschien komt dat doordat er vorig jaar nog allemaal spannende onbekende nieuwe dingen waren die heel erg uitgebreid belicht werden, maar er nog niet waren. Nu ging het vooral wat dieper op de dingen in de nu al uit zijn, maar dan soms ook weer niet diep genoeg, niet met de juiste uitgangspunten (voor mij) of een beetje te chaotisch (zoals de laatste sessie). Maar dat betekent niet dat het geen geslaagde dag was; ik heb toch weer wat geleerd.