Na enkele maanden in beta te zijn geweest, is er nu eindelijk Visual Studio
2008 Service pack 1. Op zich waren veel features al bekend maar de beta had ik
laten schieten en dus ben ik best onder de indruk van wat er allemaal in zit.
Wil je het allemaal nog eens nalezen dan mag je best wel de tijd nemen. Na drie pogingen en enkele uren installeren (tijd genoeg dus voor het leeswerk) stond het weer netjes op de harde schijf en het voelt dan toch een beetje alsof je een kadootje uitpakt.
Nu zit er genoeg in SP1 voor vele avonden uitzoekwerk maar ik wil hier het
Dynamic Data Web Application project bespreken. Het is een hele mond vol terwijl de project de eenvoud zelfe is / kan zijn.
Wat doet het dan? De DDWA genereert aan de hand van een opgegeven Entity Data Model context of een LINQ to SQL context voor alle opgegeven tabellen navigatie, gefilterde overzichten en CRUD onderhoudschermen. En dit alles is nog configurabel ook. Voordat u nu direct alle webontwikkeling wilt stilleggen, wil ik er toch even op wijzen dat dit niet de ‘silver bullet’ is. Zoals met veel
zaken moet ook dit met mate toegepast worden.
Na het starten van een DDWA project (voor LINQ to SQL) of de DDEWA
project (voor het Entity framework) zijn er maar twee handelingen nodig! Eerst
moet de database in een model gevangen worden. Genereer dus binnen het project voor een (SQL Server) database een ADO.NET Entity Data Model (Model.edmx) of een verzameling LINQ to SQL klassen (DataClasses.dbml). Voor beide handelingen is een wizard aanwezig dus daar kom je wel uit.
Dan start de magie: ga naar de Global.asax en haal het commentaar weg voor de
regel beginnende met model.RegisterContext.
model.RegisterContext(typeof(EntitiesContext),
new ContextConfiguration() { ScaffoldAllTables = true }); // Let op: True
OF
model.RegisterContext(typeof(DataClassesDataContext),
new ContextConfiguration() { ScaffoldAllTables = true }); // Let op: True
Een scaffold is een steiger. Door de ScaffoldAllTables waarde op true te
zetten worden automatisch alle in de context aangetroffen tabellen ‘in de
steigers’ gezet. Start de applicatie en zie wat er allemaal gegenereerd
wordt.
En ja, het ziet er aardig uit maar hoe pas je het in je project toe? Mijn
eerste gedacht is dat nu op een heel Agile manier het onderhoud van b.v.
stamtabellen toegevoegd kan worden aan het project. Dit betekent wel dat er een
tweede webapplicatie opgeleverd wordt maar er zijn mogelijkheden om een dynamic data website met maatwerk te combineren. Ook is het zo mogelijk om ‘power’ tester een simpel kijkje in de database keuken te geven. Hierbij wordt het dan ook mogelijk om b.v. bepaalde velden te wijzigen. Wellicht ideaal om toch te kunnen anti-dateren?
Wil je meer of minder tabellen zien, pas dan gewoon je context aan. Maar hoe
kunnen tabellen uit het onderhoudscherm weglaten worden welke in een bestaand model aanwezig zijn? Dit kan via het scaffolding (steigeren?) gedaan worden. De tabellen worden ieder door een entity vertegenwoordigd. Maak een partial class aan voor de tabel welke verborgen moet worden. Zet hierna op de klas het attribuut [ScaffoldTable(false)]. Er is overigens een aardige wisselwerking met ScaffoldAllTables om in te stellen welke tabellen wel en niet zichtbaar
zijn.
Als een kolom onzichtbaar gemaakt moet worden, is er net iets meer werk
nodig. Er is wel een attribute [ScaffoldColumn(false)] maar het is niet mogelijk
om op de partial class de eigenschap te herhalen om het attribuut daarop te
herhalen.
Hiervoor maken we eerst een extra klas aan met eenzelfde eigenschap als de te
verbergen kolom.
[ScaffoldTableAttribute(true)] // steiger
public class EntiteitMetadata
{
[ScaffoldColumn(false)]
public Object Waarde { get; set; }
}
Deze klas is een meta beschrijving en wordt op de partial klas geplaatst via
het MetaDataType attribuut.
[MetadataType(typeof(EntiteitMetadata))]
public partial class Entiteit
{
// plaats hier b.v. een property beschrijving met extra attributen
}
Binnen het project is in de map \DynamicData\FieldTemplates een verzameling
usercontrols opgenomen. Dit zijn de controls (default field templates) welke
gebruikt worden voor het representeren en onderhouden van de waarden in de
kolommen. Deze zijn te wijzigen maar die wijzigingen gelden dan voor alle
pagina’s in de gegenereerde website.
Er wordt bij Dynamic Data Web applicaties veel met conventies gewerkt. Voor
de field templates geldt dat templates, aanwezig met _Edit in de naam, specifiek
bij wijzigen van kolommen worden toegepast. De templates zonder _Edit zijn voor alleen-lezen gebruik.
Wat betreft conventies is het ook nog mogelijk om specifiek voor bepaalde
tabellen aparte schermen te definieren. Meer hierover wordt hier uitgelegd. Maar je kunt je hierbij al snel verliezen in het ‘goldplaten’ binnen het redelijk strikte keurslijf van de Dynamic Data Web application conventies.
Conclusie, wat een gouden greep lijkt om snel een user interface op te
leveren richting de klant kan al snel tegen je keren als je meer wilt dan alleen
maar wat data ophoesten. Zo is het lastig om data b.v. alleen maar readonly aan
te bieden. Maar al met al is het handig om functionaliteit voor het onderhoud
van stamtabellen hiermee op te leveren totdat deze typische adminstrator
schermen binnen het project een echte invulling hebben gekregen.
Sander van de Velde 