Linq2SQL for a new project

Question

EDIT

Appreciate all the inputs guys. Opinions were very welcome, I think we'll go with an L2S implementation at this point and just roll-up/encapsulate our DAL in such a way that if we need to change to EF in the future, it won't be too painless an operation.

As it was pretty subjective, points go to the poster with the most upvotes.

ORIG

I've been trying to keep up to speed on the whole Entity Framework Vs. Linq2SQL topic and there's already some Q's on SO e.g.

Entity Framework Vs. Linq To Sql

What I'm wondering is (opinions welcome) if you were kicking off a new major project, would you use Linq2SQL for your Data Access Layer.

To give some context, we're a .NET C# House, DB is SQL Server 2000 but we'll possibly be porting that to SQL 2005 later this year. And out of our small dev team, I'm the only one with any C# 3.0 / .NET 3.5 experience. Everyone else on the team has been stuck in 1.1/2.0 land for the past 3 years using hand cut ADO.NET & SqlHelper code for the Data Access Layer.

I guess, my main worry is we'll kick off this new project with something which is more advanced/usable/quicker to develop with (i.e. L2S) but ultimately, it's already obsolete.

Should we take the hit, delay the project and investigate using the Entity Framework in VS2008.

Cheers for any input guys.

Answer 1

I believe, certainly in the medium term, that Linq is here to stay. It has a shorter learning curve than EF (or at least it does for me) so I went that way.

Answer 2

While Microsoft continues to stand behind Linq, I suspect there is a good chance it will be trumped by the Entity Framework but they don't want to cause panic yet and are hoping that Entity Framework will prove more worthy by example.

The new features in EF 4.0 are very compelling to say the least and most of the debates were around L2S vs EF compared against EF 3.5 SP1. EF 4.0 has POCO, Persistence Ignorance, Lazy Loading, T4 templates, N-Tier support and a whole lot more.

Personally I would stand behind EF 4.0 but that is still in Beta and won't RTM till well toward the end of this year so it really depends on your schedule. That said, migrating from Linq to SQL is easier than from nHiberante or some other technology so if you need to go live tomorrow, either take a chance with Beta 1 of EF 4.0 or go with Linq to SQL.

The Beta 1 has been getting good reviews thus far and having used EFPocoAdapter (the precursor to Beta 1) I am happy to recommend it.

Answer 3

Hi,

I'd move straight into the Entity Framework (EF) with LINQ to Entities. MS has already announce the EF is the way forward for future database work and it is the technology in place for all of their new products. Because most of your developers haven't used LINQ, there's going to be a learning curve, but the code will come naturally once you're past that.

EF is more object-oriented, so it has a different feel than LINQ to SQL. For example, in EF you express relationships with objects, where LINQ to SQL allows you to specify foreign key indexes. Upcoming versions will be even easier to use. You might find it useful to follow the ADO.NET Team Blog.

Joe

Answer 4

I would go for EF in .Net 4.0. Not only I heard L2S is on maintenance mode but also EF has been improved a lot in the new version. The most important thing to me is this.

Answer 5

LINQ2SQL was created b the C# team as a way to ORM SQL structure to classes and query them in C#. EF is developed by the ADO.NET DB team and so it is MUCH more geared towards the DB side of the house then the programmer side. As ADO.NET is Microsoft's DB platform, of course they will back it more so then LINQ2SQL but that is not to say they will not be developed in parallel.

Here is a link to a page with a side-by-side comparison of LINQ2SQL and EF. This does not have all the points but many of the important ones at least.

Answer 6

Linq and the Entity Framework are two techniques that were developed at the same time by Microsoft. Linq was just supposed to allow queries on in-memory objects while the Entity framework would do the heavier database stuff. Due to delays in the Entity framework, it became a need for Linq to also be useful for queries.

If you start with a new system, the Entity framework would be my personal choice. I like the Entity model because it makes working with transactions easier and also makes working with relations between tables easier. For a project that I'm working on, I decided to use the Entity model as database layer and am building all other functionality on top of this one. By linking to the proper event, I can keep track of all edits, inserts and deletes and thus have a single entrypoint from where I can start my log. The entity model also allowed me to set up an easy website (using the dynamic data site logic) that's now used for data entry, until we have some more time to create a better solution. (Since, for now, all we need is data entry functionality.)

However, in the beginning, the Entity framework is a bit hard to use and you might end up banging your head a few times out of frustration. But if you won't give up, this technique will be quite rewarding...

Answer 7

EF needs to evolve a bit more. Some things are still lacking such as implicit lazy loading, being database focused as opposed to domain model focused etc. Read more about the Vote of no confidence: http://blogs.msdn.com/timmall/archive/2008/06/24/vote-of-no-confidence.aspx