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
It allows separation of code and database mapping easily. This is
commonly referred to as POCO
It supports more SQL features
However it seems that L2E will be enhanced to include the L2S features that
Thats a real shame and the biggest reason for me is the number of levels of
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.