Demystifying DLINQ: Part1 - An introduction to DLINQ

Posted on 6/30/2006 @ 8:53 PM in #Vanilla .NET by | Feedback | 15346 views

I hope you enjoyed my series on Demystifying C# 3.0. The idea being, 5 minutes a day, a small digestible post, that gets the point across.

a) Demystifying C# 3.0 - Part 1: Implicitly Typed Local Variables "var"
b) Demystifying C# 3.0 - Part 2: Anonymous Types
c) Demystifying C# 3.0 - Part 3: Extension Methods
d) Demystifying C# 3.0 - Part 4: Lambda Expressions
e) Demystifying C# 3.0 - Part 5: Object and Collection Initializers
f)  Demystifying C# 3.0 - Part 6: (LINQ) Query Expression Translation (to C# 3.0)
Demystifying C# 3.0 - Part 6: Expression Trees

Having taken a small break, and pondered a bit on the future direction of Demystifying *.* posts, I reached the conclusion that a Demystifying LINQ series didn’t make too much sense. The best way to learn LINQ is simply by using it. It’s a question of learning a number of query structures, and their translation to C# 3.0.

And guess what, we will be doing that anyway, in this new series –

Demystifying DLINQ

So welcome to Post #1 – “An introduction to DLINQ”. If you are new to the Demystifying series, I would strongly recommend reading up on my previous Demystifying C# 3.0 posts.

So, What is DLINQ?

DLINQ is that component of the LINQ infrastructure, that provides a run-time infrastructure for managing relational data as objects without giving up the ability to query.

I’d like you to focus on the last phrase – without giving up the ability to query.

Well, some of us are DataSet oriented, and some of us are business objects oriented. Many business object lovers criticize a DataSet as being useless/worthless. You guys couldn’t be any more stupider.

See, both DataSets and Business Objects have their own advantages and disadvantages. What you business object hippies choose to ignore is that, in writing your BOs, you do gain the ability to represent your data in a more meaningful semi-structured hierarchical form, but at the same time, you have to write every damn thing yourself. You have to write your own persistence, hydration logic (ignoring the ORMs out there), and at the very heart of it, you loose the ability to query your data.

So you end up writing everything yourself, custom to your domain, and argue that it’s better than a DataSet. Well DUH!! For the effort you put into it, it better be. (Please also read - Are you a business object person, or a DataSet person).

But that is where DLINQ comes in – it lets you work with your Data, as Business Objects, without giving up the ability to query your data.

Here is a rather simple example demonstrating what I’m talking about.

Suppose you had a really simple BO that could be represented using the following code –

public class Customer
      public string CustomerID;

      public string City;

Well, decorate it with a  few attributes and you get this –

public class Customer
      public string CustomerID;

      public string City;

And now you can query your data like this –

// DataContext takes a connection string
DataContext db = new    DataContext("c:\\northwind\\northwnd.mdf");

// Get a typed table to run queries
Table<Customer>Customers = db.GetTable<Customer>();

// Query for customers from London
var q =
      from c in Customers
      where c.City == "London"
      select c;

The DataContext class allows you to represent an abstraction of your database, and guess what – you can strongly type it as follows –

public partial class Northwind : DataContext
      public Table<Customer>Customers;
      public Table<Order>Orders;

      public Northwind(string connection): base(connection) {}

Which then simplifies your querying to as follows –

Northwind db = new Northwind("c:\\northwind\\northwnd.mdf");

var q =
      from c in db.Customers
      where c.City == "London"
      select c;

foreach (var cust in q)
      Console.WriteLine("id = {0}, City = {1}",cust.CustomerID, cust.City);

Gotta say, that’s pretty neat ;-).

Practical Tip: Now it is important to realize that “var q” is not a Query, it is merely the potential to execute a query. The query executes in the foreach – very much like a data reader. And yes you guessed it right – it makes sense to keep that loop tight for connection pooling reasons.

A few things jump out straight away –

a) This code is fully strongly typed, none of that embedding SQL Queries as strings with no compile time validation.

b) I am working with a Business Object, not a dumb bucket of rows and columns (read DataSet).

c) But what about other OO concepts like Inheritance/Data hiding?

d) What if you inherited a stored procedure oriented system, or your DBA insists on enforcing security via stored procedures (which is quite lame), and your NTM (Non-tech-manager) agrees with him (which is real life).

e) How do I know if the query being executed is efficient or not?

f) How do I save changes back into the database? How do I do conflict detection and resolution/Concurrency checks?

g) If I’m working with a DataContext, how would querying and persistence work in ASP.NET, where I would theoretically need two separate DataContexts – one during Page_load, and the other during Page_Load with PostBack = true?

Damn that’s a lot of questions – and there will probably be more – which will all get answered in this Demystifying DLINQ series.

Stay tuned.

Sound off but keep it civil:

Older comments..

On 9/3/2006 11:11:23 PM vikram said ..
This was refereshing on DLINQ. Love this new technology

On 9/4/2006 3:24:16 PM Sahil Malik said ..
Thanks Vikram - you should check out the posts I am doing lately on how all this will affect your architecture in general.

On 9/6/2006 2:21:31 PM mazugrin said ..
Okay, it looks almost exactly like NHibernate, which is what most of us "business objects hippies" were probably using anyway.

On 9/6/2006 3:37:01 PM Sahil Malik said ..
It doesn't look like NHibernate. It isn't even in the same zipcode. What are you talking about?

On 9/4/2008 3:38:21 PM dotNetter said ..
"You guys couldn’t be any more stupider." Wow, I just quit reading right there.

On 11/1/2008 11:19:21 AM newtoc# said ..
these are very helpful for me, because i come from the network world. i am using c#/linq in an application i am working on and your posts are clear and concise. thank you!

On 4/2/2009 11:09:21 AM Sameer Alibhai said ..
@dotNetter "You guys couldn’t be any more stupider." Wow, I just quit reading right there.

Lol don't take it so personally. I read this and laughed since I fall into this crowd of DataSets being useless (well, not useless but.....) :P

On 4/2/2009 12:42:21 PM Anony-mouse said ..
Sameer - some people have sand stuck in their vaginas, and they're way too testy and sensitive. But I agree with you! I love Sahil's writing style

On 3/8/2010 4:35:37 AM uddhav said ..

On 7/13/2010 2:22:03 PM Basavaraj said ..
Excellent Article. Just took 2 minutes to understand LINQ to SQL. Keep writing like this, I have become great fan of you