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.
-
Source Click Here.
Post a Comment