Vandaag was ik bezig met het maken van m'n basis weblog functies.
Nu was ik belandt bij het aanmaken van posts, toch wel een essentieel onderdeel. Als identifier maak ik gebruik GUID's en in SQL heb ik dan de newsequentialid() gebruikt.
Uiteraard is dit enorm handig, maar niet direct in combinatie met L2SQL.
Wanneer je zelf geen actie onderneemt dan wordt er gewoon een lege guid toegevoegd.
Gelukkig vond ik al redelijk snel een oplossing hiervoor op Nick Kusters z'n weblog (http://www.nickkusters.com/ViewArticle.aspx?ArticleID=29)

Je moet dus zelf in de designer aangeven dat de waarde in de database wordt berekend.
Dit kun je zelf ook aangeven in je mapping.xml, maar dan zou je dit iedere keer moeten doen wanneer je deze update.
Aangezien ik daar niet zoveel zin in heb, moest ik maar weer eens testen of een dbml-bestand toch geen optie is.
Gezien m'n vorige post hier, is dat dus ook weer gelukt.

Zo zie je maar weer dat je toch een beetje vertrouwen moet hebben in Microsoft development en niet eigenwijs bezig gaan.

Vorige week had ik het er over dat de standaard dbml-bestanden die je kunt maken in Visual Studio 2008 niet goed genoeg zijn, aangezien je die lastig in een n-tier situatie kunt gebruiken.

Hier moet ik weer op terug komen.
Ik ben nu iets meer ervaren in het hele L2SQL gebeuren en zie nu dat ik niet gelijk had. Je kunt een dbml-bestand prima gebruiken in een n-tier situatie.
Je kunt dus gewoon via de user-interface je spullen blijven bewerken, zonder gebruik te maken van SQLMetal.
Dit is uiteraard goed nieuws, afgezien van het feit dat ik nu al een week zit te prutsen met SQLMetal.
Ok, hierdoor heb ik wel wat ervaring opgedaan hoe L2SQL werkt en dergelijke.
Het is dus niet volledig verloren tijd en ik ben blij dat ik er nu met m'n thuis-project achter kom in plaats van op het werk.

Nou ja, nu ga ik dan maar weer m'n dbml-bestand aanmaken en de rest weggooien.

Eigenlijk kan alles gelijk blijven aan wat ik nu heb. Waarschijnlijk moet er her en der wat aan worden gepast, maar dat zal niet enorm erg zijn.

Dus wanneer je gebruik gaat maken van L2SQL, maak dan gewoon een dbml-bestand aan en ga niet eigenwijs je eigen spullen aanmaken.

Zo, ik heb het voor elkaar.
Met de methode hoe ik nu LINQ to SQL heb toegepast in m'n solution kan ik toch de aloude n-tier architectuur blijven behouden.

Om dit te bewerkstelligen moet je jammergenoeg wel afstappen van de eenvoudige grafische user interface die Visual Studio 2008 aanbied. Je moet nu namelijk van de console applicatie SQLMetal.exe gebruik maken.
Ook wel te doen natuurlijk, maar het is een beetje jammer dat dit niet standaard in VS.Net 2008 kan.

Eerst heb ik vandaag enkele posts van Scott Guthrie doorgelezen.
De belangrijksten waren deze wel.
Using LINQ to SQL (Part 1)
http://weblogs.asp.net/scottgu/archive/2007/05/19/using-linq-to-sql-part-1.aspx

LINQ to SQL (Part 2 - Defining our Data Model Classes)
http://weblogs.asp.net/scottgu/archive/2007/05/29/linq-to-sql-part-2-defining-our-data-model-classes.aspx

LINQ to SQL (Part 3 - Querying our Database)
http://weblogs.asp.net/scottgu/archive/2007/06/29/linq-to-sql-part-3-querying-our-database.aspx

LINQ to SQL (Part 4 - Updating our Database)
http://weblogs.asp.net/scottgu/archive/2007/07/11/linq-to-sql-part-4-updating-our-database.aspx

In een van deze posts stond een linkje naar een video post van Mike Taulty. Op zijn weblog heb ik het volgende filmpje bekeken:
http://mtaulty.com/videos/nuggets/l2s/04_mt_l2s_codegentools.wmv

Dit is een enorm informatief stukje over LINQ to SQL.
Wanneer je dit filmpje hebt gezien kun je met een beetje fantasie wel begrijpen hoe je nu een n-tier architectuur kunt toepassen.

Ten eerste maak je de mapping XML en mapping CS bestanden aan.
Zelf heb ik dit gedaan door de volgende command-line te gebruiken in de Visual Studio 2008 Command Prompt in te tikken:

sqlmetal.exe /server:. /database:Weblog /map:WeblogMapping.xml /pluralize /namespace:Weblog.Information

Nu worden je mapping bestanden aangemaakt.
Deze zet je in een project waar je normaliter je information packages plaatst.
Het verschil met vroeger is dat je nu 1 groot CS-bestand hebt met daarin alle packages. Het XML-bestand dient voor de daadwerkelijke mapping naar de database. Het CS-bestand is alleen nodig om de objecten bruikbaar te maken in je code.

Nadat je dit hebt gedaan maak je vanuit je DataAccess laag een reference naar je project met de information packages.
Nu kun je vanuit je DataAccess gebruik maken van de objecten die zijn gedefinieerd in je information packages project. Je zult dit project uiteraard ook moeten toevoegen aan de Business- en Presentatie-laag, maar dat deed je vroeger ook al. Het grote voordeel van deze methode is dat de mapping bestanden geen Select, Insert, Update en Delete functies bevatten. Al je lagen kunnen dus niet geen verbinding maken met de database. Dit is alleen weggelegd voor de DataAccess.

Een stukje testcode dat ik nu in m'n DataAccess heb staan is dit:

DataContext ctx = new DataContext("server=.;database=Weblog", XmlMappingSource.FromUrl( System.IO.Path.GetDirectoryName(System.Reflection.Assembly.GetExecutingAssembly().GetName().CodeBase) + @"\\WeblogMapping.xml"));
Item item = new Item();

var query = from c in ctx.GetTable() select c;

foreach (Item c in query)
{
//Doe iets
}

return;


Deze code slaat natuurlijk nog nergens op. Het is dan ook een voorbeeld van hoe je gebruik moet maken van je objecten en hoe je L2SQL kunt gaan gebruiken.

Het grootste nadeel is dat je nu niet meer een mooi dbml-bestand hebt en je niet meer via de grafische interface dingen kunt gaan doen.
Ook is het zo dat wanneer er een database wijziging plaats vind je opnieuw het cs- en xml-bestand moet aanmaken. In deze bestanden moet je zelf dus niet wijzigingen aanbrengen. Die gaan namelijk verloren zodra je opnieuw een mapping maakt. Dit is trouwens ook zo wanneer je wel gebruik maakt van de grafische interface.
Tijdens het ontwikkelen van L2SQL zijn ze er waarschijnlijk vanuit gegaan dat tijdens het ontwikkel proces het database ontwerp al vast ligt en hier niets meer aan veranderd.

Dat je geen wijzigingen kan/mag maken in de mapping bestanden is op zich niet er. Alle klassen zijn partial, waardoor je gewoon in een ander bestand eventuele extra code kunt toevoegen. Dat is dan wel aardig van de L2SQL ontwikkelaars.

PS: Denk er trouwens wel aan dat je het mapping xml-bestand altijd kopieert naar de output directory. Wanneer je dit niet doet, dan kun je geen gebruik maken van de functie XmlMappingSource.FromUrl(), aangezien er geen XML-bestand is om vanaf te 'mappen'.

Hoewel LINQ to SQL me gisteren wel het ei van Columbus leek ben ik daar vandaag niet meer zo zeker van.
Vanavond heb ik een beetje gezocht hoe je LINQ to SQL in een n-tier architectuur kunt gebruiken. Wanneer je dit in Google opzoekt zie je veel probleem verhalen en weinig successen.
Op de MSDN-site staat wel globaal beschreven hoe je het zou kunnen doen, maar een echt real-life voorbeeld is niet echt aanwezig. Tenminste niet zoals ik het graag wil zien.
Via deze link: http://msdn2.microsoft.com/en-us/library/bb882661.aspx
krijg je wel weer genoeg leesvoer.
Vooral de hoofdstukken Implementing Business Logic (LINQ to SQL) ( http://msdn2.microsoft.com/en-us/library/bb882671.aspx ) en Data Retrieval and CUD Operations in N-Tier Applications (LINQ to SQL) ( http://msdn2.microsoft.com/en-us/library/bb546187.aspx ) vond ik enigzins interessant.

Het lijkt alsof je de objecten die je vanuit je dbml bestand (LINQ) krijgt worden ge-detached wanneer je ze in een andere laag gebruikt. Zodra je de wijzigingen wilt opslaan moet het gehele originele object weer terug worden gekoppeld, samen met een kopie van het originele object met daarin de wijzigingen. Of je maakt de wijzigingen in de LINQ-laag, maar dan kan het zijn dat je zo'n 40 parameters aan een functie moet toevoegen. Dat is natuurlijk ook niet echt overzichtelijk.

Mede door deze site ben ik een beetje ontmoedigd: http://cs.rthand.com/blogs/blog_with_righthand/archive/2007/10/06/LINQ-to-SQL-showstoppers.aspx
Hier staan een paar nadelen van LINQ to SQL opgesomd waar je gelijk tegen aan loopt.
Dit staat trouwens los van LINQ to Objects en LINQ to XML. Dat kan wel goed werken, alleen L2SQL lijkt iets minder handig te zijn qua implementatie.

Een post die ik nog tegenkwam van Kevin Hoffman is hier te vinden: http://dotnetaddict.dotnetdevelopersjournal.com/adoef_vs_linqsql.htm
Hier wordt even opgesomd waarom L2E beter gaat worden dan L2SQL. Hopelijk zijn de problemen die ik nu ondervind opgelost met L2E.
Voor nu zal ik proberen m'n DAL of EAL of hoe je de laag ook maar wilt noemen, te ontwikkelen met L2SQL.

Aangezien ik bezig ben m'n weblog opnieuw te ontwikkelen, maar dan in .Net, heb ik maar gelijk gekozen voor het nieuwste framework, namelijk 3.5.
Momenteel ondersteund de provider dit nog niet, maar aangezien ze ook behoorlijk snel waren met .Net 3.0 te installeren zal 3.5 binnenkort ook wel werken.

Als eerste wil ik de DataAccess-laag maken. Eerst was ik van plan dit precies te doen zoals op het werk, maar dan met geautomatiseerde tools.
Nu bedacht ik me dat je in .Net 3.5 uiteraard ook gebruik kunt maken van LINQ. Dit is nieuw, dus ook vet om te gebruiken.
Of het echt goed is zullen we in de loop der jaren wel achter komen, maar ik wil het toch wel eens even gebruiken voordat er een subjectief oordeel over kan worden geveld. Iedereen vind de features natuurlijk wel enorm leuk, maar is het ook werkbaar?

Om dit uit te vinden heb ik zojuist heel wat teksten gelezen op bekende en onbekende weblogs en MSDN-subsites.
De website http://www.hookedonlinq.com/ heeft een duidelijk verhaal. Hier werd me in een keer duidelijk wat de verschillende LINQ versies doen. Hiermee bedoel ik dus LINQ to SQL, LINQ to XML en LINQ to Objects.
Momenteel wil ik alleen LINQ to SQL gebruiken, dus daar heb ik de meeste leestijd aan besteedt.
Wat mij opviel is dat er met LINQ allemaal dynamische statments worden gegenereerd. Dit is juist iets waar veel ontwikkelaars vanaf zijn gestapt vanwege de SQL Injection. Volgens de voorstanders van LINQ heeft LINQ to SQL hier geen last van, aangezien de dynamische queries toch worden omgezet in zogenaamde parameterized queries. Op zich leuk, maar ik wilde toch wel zeker weten of ik uberhaupt nog wel stored procedures kan gebruiken.
Hier heeft Scott Guthrie een mooie post over gemaakt: http://weblogs.asp.net/scottgu/archive/2006/06/18/DLINQ-with-Stored-Procedures.aspx
Ziet er behoorlijk eenvoudig en handig uit moet ik zeggen.

Nu had ik al veel code gelezen, maar nog niet gevonden hoe ik LINQ to SQL echt kan gaan toevoegen aan m'n project.
Dit heb ik dan weer op de MSDN website gevonden. De begin-pagina was deze http://msdn2.microsoft.com/nl-nl/library/bb384470(en-us).aspx (How to: Add LINQ to SQL Classes to a Project (O/R Designer))
Door de links op deze pagina te volgen wordt redelijk snel duidelijk hoe je het moet doen.

Het komt er op neer dat je een nieuw item moet toevoegen aan je project (Add new item... --> LINQ to SQL Classes).
Er wordt een mooi *.dbml bestand toegevoegd aan je project. Zelf heb ik deze de naam WeblogDataclasses.dbml gegeven, maar ieder andere naam zal ook wel volstaan.
Nu begint het sleur-en-pleur werk. Via de Server Explorer kun je alle tabellen die je wilt gebruiken in je project toevoegen aan de lege pagina van het dbml-bestand.

Wat ik ook wel leuk vind om te lezen is dat je ook gelijk validatie kunt toepassen met LINQ. De onderste link met de titel Walkthrough: Adding Validation to Entity Classes vertelt stap voor stap wat je moet doen om validatie toe te passen op je objecten.

Ook leuk is de Data Sources Window. Hiermee kun je snel een gebruikersinterface maken. Hoe en of je dit los kunt koppelen van de DataAccess-laag weet ik nog niet. Het lijkt me aannemelijk dat alle Entity objecten ook bereikbaar zijn in de Business- en Presentatie-laag, maar daar zie ik momenteel nog weinig van terug.
Alles staat volgens namelijk in het dbml-bestand, welke zich in de DataAccess bevind.
Natuurlijk ben ik ook nog maar een uurtje echt bezig, dus het is niet onwaarschijnlijk dat ik nog niets mis of over het hoofd heb gezien.

Nu ga ik eerst weer verder met het (af)maken van de laag.