Since the proliferation of client-server architecture, enterprise developers have generally learned to develop in a specific language for application code and another for database manipulation. Application code might be Java, C#, VB, C++, PHP and so on, but for databases it’s pretty much a flavor of SQL. I’ve written in three flavors of SQL: Oracle, MSSQL and MySQL. Well, four flavors if you consider MS Access’s own special blend.
Project LINQ, Microsoft’s Language Integrated Query, is supposed to re-invent how programmers interact with data. In other words, developers won’t absolutely need to know SQL anymore. LINQ is apparently championed by Microsoft’s Anders Hejlsberg as solving the ‘problem’ of programmers being forced to understand SQL in addition to their own programming language.
You can see this philosophy growing throughout Microsoft’s implementations. Visual Studio now comes in several flavors, one for Software Developers, one for Database Developers, one for testers, and so on. It seems as though Microsoft believes that we IT people are stepping on each other’s toes as we try to implement enterprise systems. Or maybe they think we need to be quarantined into our technology pigeonholes.
The issue I see is that the underlying n-tier architecture hasn’t changed (I’m not even sure it should), in that in the ‘real world’ of business applications, choices are made whether to put logic in the application or database level. Flexibility is the key, of course. A simple example might be a customer response form on a web app that has drop down values driven from a database. This decision would be made if the values change often, and rather than modifying the HTML/ASP/ASPX/PHP of the web app, records would simply be added or changed in the database and the changes instantly reflected without a code roll.
So why does this matter to LINQ? Well, if the database logic is badly written, the application’s performance will suffer, and of course, the opposite is also true, in that a stored procedure might return data quickly but the application performs poorly due to application code that could be more efficient. In the LINQ world, programmers are relying on precompiled code to retrieve data. Not necessarily a bad thing, but it also appears to put a lot of the logic that should go in the database potentially in the application. If a programmer has no idea how the SQL should work, he will always use the LINQ. This kind of code is why we still have massive, clunky corporate applications still being written in Access or even –shudder- Excel. After millions of dollars and research and hundreds of thousands of man hours have been poured into making relational databases that return data in the quickest, most efficient way, now we’re talking about ignoring all of that and running a layer of abstraction.
I don’t completely disagree that LINQ might serve a useful purpose to unify queries across databases and languages. However, I do wonder how extensive it is – I know that in the past I have written simple SELECT data queries and then performed sorts and gyrations in the app code – only to realize later I should have done it all in the database, making use of the more efficient SQL code and the database server hardware.
I’ll continue to review and test out LINQ, but right now I’m reserving judgment and wishing that Hejlsberg would go and add the ‘With’ keyword to C#. And make XML parsing faster while you’re at it! I need that more than a SQL abstraction layer.