Partial Classes, SQO and Casa Del Sterling!

So now I’m sitting in the booth at the Brisbane Ready Launch tour, and I’m almost at the end of the whole tour. Last night was great, with about 100 members of the technical community coming along for some beer and pizzas and general revelry. Brisbane have a great community spirit, and it was awesome to finally catch-up with a few good friends in person. Brizzie, you rocked!

And also thanks to Chuck and his wonderful wife Pilar for letting me stay over at Casa del Sterling last night, it was really nice to escape the hotel air and go for a swim at 10:30pm! And also thanks to Natasha for the awesome hand drawn birthday invite, I hope you have a great 5th birthday!

And so onto some DLINQ business ;) My little solution is going quite well, and as a result, I’ve been learning alot about DLINQ. So here are some of my discoveries/findings:

1. If you want to use the Query capabilities of DLINQ (as opposed to just using the object persistence part to jump the impedance gap), you will need to implement any queries in a DLINQ specific project, as the standard project template types in VS2005 won’t understand the query operator syntax.

2. Make sure you separate any custom code into a partial class extension of the classes that get generated by the SQLMetal utility, otherwise you will lose all that custom code each time you regen your object mapping layer.

3. If you want DLINQ to return you a collection of objects, use the Select projection operator style query, such as:

var query =

from category in Categories

where category.ID == categoryId

select category;

foreach (Categories cat in query)

// Do something

But if you want to return just one object ref, use the FirstOrDefault element operator style query, such as:

return Categories.FirstOrDefault(c => c.ID == categoryId);

4. If you intend on using DLINQ within your ASP.NET forms for example, create your own class that extends on the System.Web.UI.Page class, and implement a property that returns your DLINQ DataContext object, then extend all your ASP.NET pages from that custom page class. This will save you from having to cast out your DataContext object from the Session object each time you need to do anything with DLINQ.

Phew, so other than that, life is dandy. Catch you in Hobart everyone!