.NET 3.5: A LINQ to the Past

With the release of Visual Studio 2008 comes .NET 3.5, the newest iteration of the .NET framework. Unfortunately, .NET users are also greeted with a rise in popularity of the age-old question: Stored procedures or in-line SQL?

I won’t bore you with the details of LINQ (Language INtegrated Query) itself, as nothing can beat Scott Guthrie’s nice introduction on his blog. Something I’ve noticed about these new piece of technology, though, is that debate seems to rage up about how exactly to use it.

 LINQ has the nice ability to eliminate the need for many data layer projects and simplifies everything down significantly. To put it rather succinctly, you have the option to make a database object and call pre-made stored procedures like methods, or perform “in-line” LINQ to SQL commands.

The temptation to use in-line calls is tempting. That eliminates any database work besides initial creation and relationships. No more creating stored procedures and then calling them from code. Everything is contained in one place. You can even view your entity relations from inside of Visual Studio 2008.

However, many people point out that in-line SQL is not very efficient. The database optimizer doesn’t get a chance to be run on the query, not if it’s created dynamically. Therefore, traditionally stored procedures have been the “optimal” choice for database calls.

With LINQ, however, this may not be the case, or at least not as much as would be expected. Visual Studio magazine explains that LINQ can use eager or lazy loading to run its queries.

Eager loading loads up a ton of data at once, entire entities and relations. Lazy loading is a more “on-demand” type loading. What this means in more simplistic terms is that with lazy loading, there are many many roundtrips to the database, each one retrieving a smaller amount, whereas eager loading makes fewer trips for more data.

It seems that with LINQ, the hot topic is performance, and how to maximize it. Ultimately, you will probably take a slight performance hit from switching to LINQ. Is it worth it? That’s the question many many people around the world are asking themselves right now.

There are many methods of optimization, though, like pre-compiling in-line queries and just sucking it up and using stored procedures (which, as I mentioned earlier, can still be added to Visual Studio as methods of an entity object).

If anyone has some comments about LINQ I would be happy to hear them!

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s