To linq To SQL or not... that is the question?

Question

Our team is now beginning to look at jumping from 2.0 to 3.5 and have been reviewing all the new stuff....

So, with the whole Linq to SQL not being heavily improved in the future should we ignore it completely?

It seems that it may fit of our needs very well BUT I imagine so could entity framework even if it may add more complexity.

So avoid Linq To SQL like to plague and go with entity framework instead or jump on in, Linq To SQL will be just fine in 4.0 and future releases even without improvements?

Answer 1

Everything I've read seems to suggest that Linq2SQL will still be around for a while. I would, if I were you, just pick the one that best suits the problem you're trying to solve. I might be a little biased toward using the Entity Framework because it's more abstract and might be a good capability for you and your team to have, and because Visual Studio 2008 has a designer for it.

I just don't think it's that big a deal for a few years. Just pick the one you like the best for now.

Update: lest there be any confusion - using the EF doesn't mean giving up Linq. Linq can already be used with the EF.

Answer 2

Very similiar to my question @ http://stackoverflow.com/questions/806159/switching-to-linq

Might offer further insight/opinions.

Personally, I am going to start focusing on EF since everything I see coming from MS is that LINQ is just the beginning and a big part of the foundation of EF.

Answer 3

I would pick LINQ only because it is simpler, and when you finish your application, and are looking at optimizing, and refactoring, then you can try Entities, and see if you have any performance improvements, or if it makes the code better.

I tend to start with the simpler, faster-to-develop, method, to get the functionality finished, then I refactor, then optimize.

Answer 4

I'd have picked EF in any case. I never liked the idea that LINQ to SQL mapped directly to the database structure. I greatly preferred the idea of EF, where I can decide what entities I want to present to users, and then map them to the database tables as appropriate.

Answer 5

LINQ to SQL and Entity framework are not comets passing by. They are real coding revolutions !

We can now query databases in 1 hour where it took us 1 day before !

Do not hesitate to jump. If .Net 4.0 does not suport LINQ to SQL or Entity framework, just stick to 3.5 !

:o)

All the best, Sylvain.

Answer 6

If LINQ to SQL fits your needs, then go with it. Its really a very powerful RAD tool.

EF will give you more flexibility, but also perhaps unnecessary complexity.

Its a shame LINQ to SQL isn't moving forward anymore, but I'd stick to it until EF really matures and allows equal RAD development, unless of course, you need EF features now.

Answer 7

I would say that it depends. Everyone else so far has put things very well.

Use LINQ-to-SQL if you don't mind the fact that your eventual object model is going to very closely mirror your database. There's not a lot you can do with or to a LINQ-to-SQL model if you find that you want to model things differently.

Use EF if you want to potentially use the same framework to point to multiple types of data, or if you'd like to abstract your database model more than is possible in LINQ-to-SQL.

I don't have any data on, say, performance differences between the two models, unfortunately.

I wouldn't say the fact that MS isn't doing a lot of active development on LINQ-to-SQL should necessarily scare you away. Its a very good, very, very basic object mapping solution.