Gisteravond was het gezellig in de Tube Station, een trendy clubje in het
centrum van Berlijn. We waren uitgenodigd op de Belgian Country Drink. We hebben dus uitvoerig de voors en tegens van bier consumptie gesproken 🙂
Voor vandaag stonden wéér meerdere sessies op het programma. Dus net als
gisteren zal ik er enkele uitlichten.
Managed Extensibility Framework
In het verleden heb ik meerdere ‘paraplu-applicaties’ geschreven. Hierbij was
het mogelijk om meerdere DLL’s met daarin verschillende overervingen van
dezelfde interfaces in te laten en te consumeren. Het koste wel wat werk met
reflection maar werkte heel aardig. Dit zal ook de basis zijn voor veel
factories en Inversion Of Control frameworks.
Dit kan ook met Managed Extensibility Framework. MEF is aanwezig in het
.Net 4 framework. Hierbij schijf je eerst een aantal klassen die je wilt
consumeren en die dus een Export attribuut krijgen. Met dit attribuut beschijf
je een unieke benaming van de ‘dienst’ die zo’n klasse biedt.
Vervolgens schijf je de code die gebruik maakt van een gewenste dienst en
wel door een variable met een Import attribuut te decoreren. De Import is
uitgerust met een identificatie van wat je wilt consumeren (als identificatie
kan een string, een interface type, etc. of combinaties gebruikt worden).
Als laatste moet bij de start van het uitvoeren van de applicatie een
catalog in het geheugen opgebouwd worden van alle beschikbare Export klassen.
Dit kan bv. door een map op schijf te laten onderzoeken. Dit is dan mogelijk met
een de Directory Catalog.
Tijdens het daadwerkelijk consumeren van de variabele die met een Import
gedecoreerd is, zal via het MEF de beste match gezocht worden en de juiste
Export implementatie ingevoegd worden. Mochten er meerdere exports beschikaar zijn dan zal een exception opgeworpen worden.
Dit is een eenvoudige implementatie van MEF maar dit kan ook
uitgebreider. Ik heb een demonstratie gezien voor het automatisch inladen van
bv. meerdere validatieregels. Dit kan via door het combineren van een ImportMany attribuut en een Enumerable<> member.
De DirectoryCatelog heeft een Refresh mogelijkheid om de verzameling van
Export klassen bij te werken, bv. als er een nieuwe dll ineen map geplaatst is.
Maar dit moet je zelf aanroepen (bv. met een FileSystemWatcher). MEF is hierbij passief ingesteld.
Het is wel interessant om te zien wat gebeurt als een class met een
Export, dus welke geconsumeerd kan worden, zelf ook een Import heeft maar waar die Export niet geladen is en dus ontbreekt. MEF laat dan de gehele export
achterwege voor verbeterde stabiliteit.
Dino Esposito gaf al direct aan dat wat MEF doet, ook op andere manieren
opgelost kan worden. Maar ik ben best onder de indruk van de simpliciteit
waarmee MEF toegepast kan worden.
MEF is een soort van een Inversion of Control oplossing want je kunt code
injecteren. Maar er zijn ook een aantal verschillen (sorry, de sheet was al weer
van het scherm 😦 ). Probeer het dus eens uit.
Deep dive into EF4
Zo veel te vertellen, zo weinig tijd…
Performance
Als eerste werd er eea. over performance verteld en gedemonsteerd.
IntelliTrace is hierbij je vriend. Alle queries naar de database worden getoond.
Beperk hierbij dus het aantal roundtrips, zichtbaar in de IntelliTrace. Je kunt
ook beginnen met het vroegtijdig laten uitvoeren van alle metadata in EF4 zoals
executieplannen. Roep je LinQ statemens eerst eens aan met ToTraceString(). Er
werd ook een door TT gegeneerde Klas gedemonstreerd die alle basis queries voor EF4 genereerde. Hiermee kun je EF4 flink “opwarmen”.
Als je tabellen alleen readonly gebruikt, zet dan de ChangeTracking uit
op die tabellen. Dan worden er geen versies van de records bijgehouden. (Dit is
de MergOption op de tabel).
Gebruik ook eens de profiler om de traagste linq-queries te ontdekken en
pas die aan. Er was ook een lastige voorbeeld waarbij de linq query in code
‘gecompileerd’ werd (dit ging even te snel…). De sheets komen beschikbaar dus
ik kan ze aanbevelen om nog eens na te bladeren.
Repository patterns
Dit is de scheiding tussen Model en gebruik van de entiteiten. Hierdoor kan
je je beter concentreren op de functionaliteit en wordt de code beter
beheersbaar. Hierdoor wordt het ook mogelijk om EF4 te vervangen door een
willekeurige andere oplossing zonder de businesslogica rond de data aan te
passen (een andere database er onder schuiven). Maar dat vonden ze minder leuk 🙂
Dus schrijf een repository class die een context als property krijgt en
gebruikt bij fucties zoals GetAll, FindOne, etc. een (Asp.Net MVC2) controller
gebruikt dan niet de context zelf maar consumeert de repository.
Testability
Je wilt je repository ook unittesten, niet je model. Het model wordt wel
aangeroepen door de repository. Dus als je weet wat je aan de repository
meegeeft, dan weet je ook wat je er uit mag verwachten. Dus hoe bouw je een fake context?
Leidt eerst een interface af vande bewuste context. En injecteer de
interface in de repository. En de bestaande controllers worden via een extra
controllerFactory aangemaakt waarbij de EF4 context uiteindelijk in de
controllers geinjecteerd worden. En dan kan je de objectsets ‘mocken’ voor de
unittest. (code uit de demo’s komt beschikbaar). Dit heb ik in het verleden
geprobeerd maar toen werkte het bij mij niet. Dus dit ga ik zeker nog eens goed
uitzoeken! Ik heb nog even gevraagd om de demo code en die gaat zeker online
beschikbaar komen!
N-Tier/Disconnected
Gebruik alleen een N-Tier oplossing als je dit echt nodig hebt. De
complexiteit gaat enorm omhoog en de beheersbaarheid omlaag. Maar als je het
toch wilt of nodig hebt, gebruik kan WCF samen met Self-Tracking objects uit
EF4. Je kunt TT templates laten toevoegen aan je model met daarin Self-Tracking (poco, etc.) objecten te genereren. Via de service geef je entiteiten door uit je model bij ophaalacties (Read). Maar bij update methodes (Write) krijg je
(wellicht) gewijzigde objecten terug van de clients en voer je de ApplyChanges()
op je model uit. De objecten die je uitdeelde aan gebruikers, komen dus wellicht
gewijzigd terug maar die informatie zit in de objecten zelf (vandaar
Sef-Tracking). Serverside is de context dus even onwetend. Dit zag er heel
aardig uit, zelf met een op de Database gegenereerde PK.
Dat was het weer voor vandaag. Overigens zal deze en andere informatie de
volgende maanden via XPG sessies beschikbaar komen.
Groetjes uit Berlijn!
PS: Voor degene die eens aan de slag willen met MEF… http://goo.gl/qKhLV
Sander van de Velde 