DLINQ Travels!
I’m working on the next release of https://www.devgarten.com (https://www.devgarten.com is now available for the security conscious ;)) and I’m adding the News and Events section. The underlying App Arch to this is SQL Server 2005 as the data source, LINQ/DLINQ as the data coupler, and ASP.NET 2.0 as the presentation tier.
Couple of things I’ve come across over the last few days with DLINQ:
1. When you generate your intermediate class from SqlMetal, add a partial class that extends the generated code to store your queries. As you can’t embed LINQ queries into ASP.NET classes yet, you’ll need to co-locate you queries with the data objects. So I’ve got my generated class like:
public partial class DevGartenDataObjects : DataContext
And then I have another class file called DataQueries.cs with:
public partial class DevGartenDataObjects
{
public IEnumerable<DevgartenNews> GetNewsList()
{
return DevgartenNews.OrderByDescending(n => n.PublishedDateTime);
}
This allows me to write code in my client such as:
private void LoadNews()
{
newsList.DataSource = DevGartenDataContext.GetNewsList();
newsList.DataBind();
}
2. Not everything generated by SqlMetal works. I include a timestamp column in the events table, but when the collar class is generated by SqlMetal, it’s marked as the DbType “rowversion” which just don’t work, so you need to dig into the class and change it to “timestamp”. This is a bit of a pain if you are generating regularly, as you then need to track the fields that need changing.
If anyone is getting nasty with DLinq, and are running into any probs, drop me a line, always happy to have a squiz ;)
3. If you want to make accessing the DLinq layer a little easier in ASP.NET pages, I’ve started doing this:
a) Create a utility class in your App_Code folder under your ASP.NET project tree called DlinqConsumer, and create a class that inherits from the System.Web.UI.Page class.
b) Create a property in the class that returns your data object type (this is the root class generated by SqlMetal, and represents your data context object)
c) In your Global.asax file, on the Session_Start method, create a session variable to store your data context object, and initialise it from a setting in your web.config file. Also close it off in the Session_End method.
d) When you create pages that will interact with DLinq objects, inherit from your consumer base instead of the standard Page class, this way, you’ll always have the magic data context accessor property. This saves you from having to manage the connecting and disconnecting of the data session with DLinq.
My only concern is about storing the data context object in a session variable, but I’ll monitor this over the time of the web site to see that actual impact on the app and server performance.