Whats the score with LINQ to SQL?

LINQ to SQL (and any ORM for that matter) has the marmite factor. You either love it or hate it. Whats more many of those that hate it haven't tried it. In many cases the hate it crowd are making a decision based on previous experience with systems using ORM solutions.

I've been looking at and trying to use LINQ to SQL for a while and thought I would post my findings thoughts. Before starting this series of posts I thought I would see what others have said. I had heard something about an announcement about LINQ to SQL and LINQ to Entities and found the post hear. http://blogs.msdn.com/adonet/archive/2008/10/31/clarifying-the-message-on-l2s-futures.aspx

I made a conscious decision to look at L2S rather that L2E for these reasons,

1.      Its simpler

2.      It allows separation of code and database mapping easily. This is commonly referred to as POCO

3.      It supports more SQL features

However it seems that L2E will be enhanced to include the L2S features that are missing.

Thats a real shame and the biggest reason for me is the number of levels of interpretation.

When you right a LINQ query with L2S your LINQ query is translated to an expression tree and then translated to SQL.

With L2E you have an extra step because the entity framework is a framework that sits on stop of any provider (that has been written). To enable that it has its own data access language Entity SQL. So to get to SQL, your LINQ query is translated from LINQ to ESQL to SQL.

Anyone thats worked or seen translated text will know that often what you put in is often not what you get out. There is a common games on radio in the UK where they translate an album/track name to a language and then back to English. The quiz is then to guess what the original album/track name was given the final translated text. (A bit like Chinese whispers).

We all know how complex SQL is, so you can understand why generally the SQL you get from L2E is more complex than with L2S.

I personally like to keep things simple and so I’m disappointed by the decision to concentrate. Although all is not lost.

If you use standard practice of implementing a data layer then you could move to L2E in the future. Whats more your SELECT LINQ queries against a set of L2E objects should be similar to those for L2S. The main difference is when you want to do your insert, update and delete operations, the two technologies use different mechanisms. Further more you will likely have to change you validation code to use the different technology, although the core rules code shouldn’t have to change.

I would still stick with L2S until the next version of EF. I'll discuss some of my findings in future posts.


Published Sunday, November 16, 2008 12:16 AM by simonsabin


# Dew Drop - Weekend Edition - November 15-16, 2008 | Alvin Ashcraft's Morning Dew

Pingback from  Dew Drop - Weekend Edition - November 15-16, 2008 | Alvin Ashcraft's Morning Dew

Sunday, November 16, 2008 8:30 AM by tonyrogerson

# re: Whats the score with LINQ to SQL?

LINQ to SQL's biggest advantage is its biggest drawback - the embedding of SQL inside the application.

We buried that method and correcly decoupled the data access logic from the application back in the early 90's.

Tightly coupling your application data layer with the database is a very bad thing; it offers no flexibility when problems happen - the SQL can't be modified (look at products where that is true and look at the problems and associated costs come with that).

Thankfully - there are a lot of people out there who know and understand this and it looks like Microsoft are finally having a realisation burying your SQL in your application is not what people want out in the real world.


Monday, November 17, 2008 8:37 AM by rmaclean

# re: Whats the score with LINQ to SQL?

What about the recent announcements from the team that L2S is not the recommended system going forward. Surely anyone thinking about using either L2S vs L2E must factor in long term support from Microsoft and that it appears that L2S won't be supported for too long.

Your forth paragraph starts with: "With L2S you have an extra step because the entity framework"

Should that not be L2E?

Monday, November 17, 2008 9:58 AM by simonsabin

# re: Whats the score with LINQ to SQL?

Thats the announcement I linked to. Its not that LinqToSQL won't be supported its just that they aren't going to develop it. As has been pointed out both have features that the other doesn't so MS did have to make a decision to progress with one.

However The complexity, IMHO, of L2E is a barrier to entry so if you want a simple approach then you should go with L2S. In a recent survey about ORM technoogies being used, L2E had a fraction of the implementations of L2S. I would therefore expect some means of going from L2S to a future incarnation of L2E.

I don't beleive that will be for quite a while and so sticking with L2S is a viable option for apps being written now.

Fixed the error as well, thanks

Wednesday, November 19, 2008 1:03 AM by SimonS Blog on SQL Server Stuff

# LINQ to SQL – Abtsracting your database.

One of the arguments often put forward against the use of any (Object Relational Mapping) ORM, whether

Friday, December 12, 2008 9:59 PM by SQL Server 2008 (SSQA.net)

# LINQ to SQL - will this be a future of database development?

Since the CTP of SQL Server 2008 there has been much of traffic going around talking LINQ is a replacement