Dave's worried about LINQ
I'm still worried about SQL style syntax in code - where should it go? Should we abstract it into a separate layer? Should we not have stored procedures anymore?
[Via writerus drivelus]
I can appreciate the concern. Of course, specifically what Dave's worrying about here is DLINQ - the data access technology that allows you to use C# 3.0 and VB 9 syntax to write database queries in your code. He's also concerned about the VB9 XLINQ syntax that lets you embed XML in your code - and then embed code in that XML. Indeed - there's a blending of layers and concerns here that is really quite disturbing.
What's driving this unease is the coming together of a number of seperate powerful technologies, which individually offer amazing programming gains, but together create the potential for more complexity than you can imagine.
Personally, I agree - DLINQ seems likely to be a pretty ugly way to access databases, encouraging developers to write crazy queries with little concern for performance, and rendering possible optimizations to data access code opaque and difficult to implement. But LINQ is way more than just DLINQ.
Much more profound is the bold decision made by Anders Hejlsberg et al to make the LINQ syntax in C# itself just a dumb macro language - but a very cleverly designed one. It seems to render the compiler almost psychic in its ability to track data types, and allows you to write deeply expressive code. Here's a quick LINQ example that uses the C# 3.0 language features directly to construct a very intuitive API syntax for filesystem access:
public class Program
{
public static void Main(string[] args)
{
DirectoryInfo dir = new DirectoryInfo(@"C:\");
var fileNames = from f in dir where f.Name.StartsWith("a") select f.Name;
foreach (var name in fileNames)
{
Console.WriteLine(name);
}
Console.ReadLine();
}
}
public static class DirectoryExtension
{
public static IEnumerable<FileSystemInfo> Where(this DirectoryInfo dir, Predicate<FileSystemInfo> predicate)
{
foreach (FileSystemInfo fsi in dir.GetFileSystemInfos())
{
if (predicate(fsi))
{
yield return fsi;
}
}
}
}
I love the fact LINQ lets me do this sort of thing.
What I love even more is that you can change the argument type to the extension Where method from Predicate<FileSystemInfo> to Expression<Predicate<FileSystemInfo>>. This means that instead of being passed a simple, executable delegate that acts as a predicate, you get a structured lambda expression. You can then analyse the lambda to determine, for instance, that all the user wants to do is filter the filename list by whether the name equals a certain string. In which case you can optimise the logic so you don't iterate through all the files in the directory, but instead use one of the more specific APIs to go direct to the file or files they're interested in. All through really expressive bits of code like this:
var files = from f in dir where f is FileInfo select f;
var oldFiles = from f in dir where f.CreatedDate + new TimeSpan(28,0,0,0) > DateTime.Now select f
So there's a lot of really useful power here - it's not just a demo gimmick. I can think of real ways I can really benefit from using LINQ, lamdas, and extension methods. I'm genuinely looking forward to C# 3.0...