Original URL: http://www.theregister.co.uk/2007/12/10/linq_basics/

Mind your languages with Microsoft LINQ

Data-access sticking plaster?

By Mark Whitehorn

Posted in Software, 10th December 2007 01:02 GMT

We've been hearing a growing amount this year about LINQ - Microsoft's Language Integrated Query. You can expect a lot more next year, starting in February as Microsoft launches Visual Studio 2008 and SQL Server 2008. LINQ promises to close the skills and knowledge gap for developers using C# and VisualBasic trying to connect to different data types and sources.

Before Visual Studio and SQL Server 2008 hit, here's what you as a programmer need to know about LINQ.

LINQ was created as the solution to a communication problem. Most modern programming languages are Object-Oriented (OO) while much of the world's data is stored in relational databases. Application programmers are used to dealing with things such as objects, classes and methods but they are not usually familiar with SQL - the language used to query relational databases.

As Anders Hejlsberg - the noted language expert and designer of Microsoft's C# - has argued, this has created: "An impedance mismatch today between general-purpose programming languages and databases. LINQ adds native query capability into programming languages such as C# and VisualBasic."

At a very simplistic level, LINQ can be seen as an OO querying language that can be understood and used by OO programmers and yet run against relational structures. But whilst this describes the way that it will often be used, LINQ actually does a lot more and is described by Hejlsberg and colleague Don Box here as: "General-purpose query facilities added to the .NET Framework [that] apply to all sources of information, not just relational or XML data."

So LINQ allows application programmers of an OO mindset to query any data source (Relational, OO and XML) in a way that they find intuitively easier. It is not, despite what some people have written, a replacement for SQL. To be explicitly clear about this, whilst DBAs are, of course, free to use LINQ if they so wish, there is no suggestion that it will become their language of choice.

For programmers, one of the best resources I've found for getting one's brain around LINQ is the intriguingly labeled 101 LINQ Samples for Visual C# that can be found here. Intriguing, why? Because there are actually 99 samples. Oh, those Microsoft clowns.

So does LINQ open the door to a pain-free world? I never said that. Most people would agree that there is an "impedance mismatch" between general-purpose programming languages and databases. We can, though, essentially address this problem from either end.

The application developer-centric approach is to make the database - or any source of data - look like a data structure in an application, which is how LINQ addresses the problem. The database-centric approach has always been that the application developer has to learn SQL.

Given that Hejlsberg has mainly worked on the application language side, it is not surprising that he favors the former approach and, given his experience, these views are well worth very taking seriously.

It just isn't that simple, though. For a start, it can be argued that LINQ is a solution to a problem that shouldn't exist. For example, Hejlsberg has argued that application developers currently: "Have to learn database languages such as SQL and what comes with it, such as stored procedures and data types, while also mastering programming languages such as C#, VisualBasic or even Java."

In a well-designed database it is possible to use features like stored procedures to completely shield the application developer from the tables and therefore the need to write SQL.

To try to forestall comments pointing out that most databases are not well designed and that a knowledge of SQL is essential in order to reach the data therein, I'd like to say: "I know - I agree". But that doesn't stop people arguing that LINQ is treating the symptom, not the disease. Instead of applying the LINQ plaster to the gaping wound, we should be making it easier to create an abstraction layer in the database. Application programmers could then write against that layer rather than the actual tables.

This would also address another criticism leveled at LINQ, which is that whilst it isn't SQL, it still writes directly to the tables. As soon as the table structure is altered, the application breaks.

The bottom line is that it is impossible to know as yet whether LINQ will succeed or fail; ultimately that will depend on whether application developers use it or not. The fact that Microsoft is behind LINQ will encourage some and discourage others. The support of Hejlsberg will influence yet others, myself included, to at least give it a go.®