Linq 2 SQL or Linq Entities

Question

I am starting to design a new application and what I am wondering is peoples opinions on Linq2SQL or Linq2Entities and what they feel is the better technology for rapid development.

I am also doing some research into ADO.net data services.

Answer 1

Yes, agreed with Slace.

Just be careful on the framework you do choose, to ensure it meets all your needs.

For instance, I recently gutted out Entity Framework from a work project after working with it pretty solidly over the last couple of weeks, as it did not facilitate my needs, mainly due to:-

1. The things you can't do in Linq to Entities (such as mapping to .net enum types (grr) and the aggravation of receiving 'NotSupportedException' at nearly every turn if you try to get fancy in your linq query statement by calling on function or method calls (see link)).
2. Lack of native Lazy Loading (I understand there is tools such as EF Lazy LoadGen to facilitate this, but it was not something I wanted to encorporate).

Other than that, commands and the framework seemed straight forward and neat, and the reason I went with EF was:

1. I believed EF was targeted more for enterprise development and thought L2S was more for hobbyists and was a limited framework. However with further understanding and personally, not needing anything in EF I couldn't do with L2S, I am happy with L2S. Especially if it suits stackoverflow, scalability and efficiency is covered for me.
2. Option for multiple DBMS' (I'm yet to see this in action however)
3. It was rumored Microsoft was dropping support and investment on Linq to SQL.
4. I love the fact you can update tables and DB changes within the EF .edmx without having to delete the existing schema model (which you are forced to do in Linq to SQL). Albeit, not super annoying unless you've customised any properties in your L2S schema (.dbml).

Further reading (another SO post):
Is LINQ to SQL Dead or Alive?

I would love to choose EF, I really do not know what to make of the L2S vs. EF debarcle, and if L2S really is a dead duck, shrug. my main gripe admittedly with EF is the NotSupportedException's - I could get around lazy loading if I could perform method calls in linq without getting this...

Answer 2

I'm a big fan of LINQ to SQL if you meet the following design requirements:

• MS SQL Server as the DB engine
• RAD development
• 1 - 1 class mapping is all that's required

I've not done a whole lot of work with Entity Framework but from what I know and what I have done is that it doesn't have as-good performance when generated from the same database as LINQ to SQL uses.

The lower performance is due to the nature of Entity Framework, it uses ADO rather than specific providers for the database server you're using.

Answer 3

I would say that for a simple to moderate database schema, Linq2SQL works very well and is easier to set up and use. This is what I use for my ORM with some small adjustments through partial classes to support validation and authorization/auditing. I use the DBML designer and add my tables/relations. I change the DataContext to make it abstract and build a concrete implementation that allows me to provide implementations of my table-valued functions/stored procedures (which map into the data context as methods) that provide hooks for auditing and authorization. I implement partial methods on the entity classes for OnValidate and OnLoad to do both validation and authorization at the table level. I find that this is pretty much all I need. Lately, I've been defining an interface and wrapper for the concrete data context as well to allow me to mock it out in my unit tests.