With LINQ to SQL most likely going to not get as much active development as Entity Framework do you think it's best to switch to Entity Framework?
I've personally found EF to be very clunky and hard to use compared to LINQ to SQL which feels very natural.
EDIT: I recently posted an article on my blog about my feelings towards this potential decision...
IMO, not at the moment.
It is clear (from recent announcements especially) that EF is in for some heavy revisions as the "thunderdome" scenario plays out between LINQ-to-SQL and EF. Whatever happens, EF (in a few years) will almost certainly look quite different to EF today. Or certainly "different enough" ;-p
As such, my view is: stick with simple. And simple is LINQ-to-SQL.
I don't see much benefit learning a notoriously complex system if I know it is going to change very soon.
And I'm 100% with you on LINQ-to-SQL ;-p
If I needed something more than LINQ-to-SQL right now, I'd look at NHibernate or maybe LLBLGen Pro.
(edit - as an update, my position has softened a little bit, here and here - but I'm still using LINQ-to-SQL as my primary tool; also - LINQ-to-SQL isn't quite dead yet ;-p).
Quite a few experienced developers have given "ADO .NET Entity Framework Vote of No Confidence" as is discussed further here.
I think we're expecting it to be improved significantly in .Net 4.0 by the ADO.Net team.
And here's some video from the recent PDC.
For the record, some hesitation about the future of LINQ to SQL has been expressed here:
I have to agree with Marc Gravell. Maybe when the next version of Entity Framework is released (.net 4.0 / VS2010) will there be an advantage to using EF, and by then it will probably be very different from the current version of EF.
Until then at least I will avoid EF like the plague for anything besides tests/experimental code that will never hit production.
The EF msdn forum is full of examples as to why EF is not ready for prime-time, but I there is one particular example that is a clear winner - what would normally be a simple five table query (10-15 lines of SQL) becomes >1500 lines of SQL when using EF and the EntityDataSource control:
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=3874607&SiteID=1
http://paste-it.net/public/q6ed5c2/
And as to the future of EF - with Microsoft's history of changing direction on big strategic things overnight, who knows if their current "strategic goal" with EF will come true a couple of years from now..? I for sure wouldn't bet on it. See:
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=4100399&SiteID=1#4107623
LINQ to SQL doesn't seem to be an option unless you use SQL Server (or SQL Server compact), so that was reason enough for me to avoid it and use EF (I wanted to use PostgreSQL).
There are definitely enough things missing in v1 of EF that would make me hesitate to recommend it. It sounds like version 2 of the EF (when released) would be the first version that could be seriously recommended for switching over to.
If you're doing database-driven development, EF has real advantages today.
I've used both LINQ to SQL and EF and worked through the many little frustrations of EF v1.
However, the one thing that made EF v1 win for me is the astonishingly good update from database wizard. Incredibly, this actually works! It may sound trivial, but if you're doing database-first design, you want to rely on tools to create your classes for you and you don't want to have to regenerate your entire model just to make a change.
This alone makes EF v1 my choice. I suggest ignoring the advanced features of EF v1 - it's nowhere near usable yet as the ambitious platform it aims to be.
Put up with the clunkiness of EF v1 and you'll be in the best position for the future.
Pete.
I've completed a few MVC projects now in production with L2SQL under the hood and found it quite a joy to use. I'm now embarking on a new project and decided to write it using EF and L2EF given the previously cited articles proclaiming the death of L2SQL. After only a couple of days I've decided to go back to L2SQL. Simple things like having to set foreign keys for inserts using either the awful syntax shown below or uneccessary lookups have shocked me.
foo.Foreign_TypeReference.EntityKey =
new EntityKey("DataContextName.Foreign_Type", "Foreign_Type_Id", ForeignTypeId);
Rather than:
foo.Foreign_Type_Id = ForeignTypeId;
I don't think it will be that hard to port L2SQL to a future version of EF as L2SQL has a subset of the functionality (though better implemented). The few things that L2SQL has that L2EF doesn't, for example Single() and SingleOrDefault(), can be migrated to EF by creating a few extension methods. I think it will take far less time to get the system running using L2SQL and then port it over later when EF isn't so smelly.
Recently, i had to research which ORM project should use. At first - tried L2S. It wasn't bad at all, but it's already obsolete (MS won't support it anymore), that's why i started to check out L2E. I'm fine with generated code, but creating fake views, entities and mappings between them just to make stored procedure available not to fill all fields of entity was an overkill for me. And i wanted to separate my dataaccess layer, so - i had to map data from generated objects to ones i made.
It took me few hours of experimenting with NHibernate+Fluent NHibernate+LINQ to NHibernate
to stick with this combination.