Geeks With Blogs
Rotten Code it can always work better - but at least it should work
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. Posted on Thursday, April 12, 2007 6:05 PM | Back to top

Comments on this post: Is the concept behind LINQ's creation wrong?

# re: Is the concept behind LINQ's creation wrong?
Requesting Gravatar...
I think you've misunderstood the purpose, as no one seriously in on the design of this or already in favor of using O/R Mapping would claim that the point is to avoid knowing Sql. I'm the creator of the WilsonORMapper and I very much think anyone worth their salt should know Sql quite well whether you use an O/R Mapper or not. So what is the purpose than? One rationale is to take the typical CRUD scenarios that really are just basic Sql statements and make them happen automatically since they are no-brainers and we really do have better things to do with our time. Another rationale is that while the code may be precompiled, this does not in any way mean that the Sql itself is all set in stone in our code -- quite the contrary, an O/R Mapper runtime can sometimes generate better optimized Sql since it knows more about the scenario than a static stored proc could ever know. The Linq project adds additional value in that it adds compile-time checks and intellisense, while still generating the optimized Sql necessary to let the database best use its horsepower for filters, sorts, and paging. There are many other benefits to O/R Mapping also -- but many of us have already documented them many times over if you actually care to read up on them.
Left by Paul Wilson on Apr 12, 2007 9:12 PM

# re: Is the concept behind LINQ's creation wrong?
Requesting Gravatar...
I'm still not sure why putting basic CRUD logic into the app is more productive. And when the CRUD logic changes, doesn't the app have to change? Anders Hejlberg is specifically quoted this month as saying the LINQ will remove the need for developers to know SQL.
Left by Marcus Shockley on Apr 13, 2007 10:53 AM

# re: Is the concept behind LINQ's creation wrong?
Requesting Gravatar...
I have another problem. I am using LINQ to SQL ORL designer and when I m using stored proc and run the application it works fine. but later after making any changes to the stored proc when I run my application, the changes are not reflected. do I need to delete and add the stored proc again or is there any way which automatically refresh those changes. Any clue of this is highly appreciated.
Left by Manish on Jun 19, 2008 1:16 AM

Your comment:
 (will show your gravatar)

Copyright © Marcus Shockley | Powered by: