views:

516

answers:

2

The relative simplicity of Linq-To-Sql as well as all the criticism leveled at version 1 of Entity Framework (especially, the vote of no confidence) convinced me to go with Linq-To-Sql "for the time being". Now that EF 4.0 is out, I wonder if it's time to start migrating over to it.

Questions:

  1. What are the pros and cons of EF 4.0 relative to Linq-To-Sql?
  2. Is EF 4.0 finally ready for prime time?
  3. Is now the time to switch over?
+7  A: 

Well, an endless debate :-)

Yes, I firmly believe EF4 is definitely ready for prime time - Microsoft has done an outstanding job of addressing just about all the annoyances and issues with the 1.0 release of EF.

It's ready for prime time - if you need all its features.

Linq-to-SQL is a pretty straightforward, no-frills, no-nonsense OR mapper - it maps one database table to one CLR object - and that's about it. Very basic, very direct - but a rather thin layer on top of SQL Server.

EF4 on the other hand is much more

  • a conceptual data model in your object space
  • a storage data model on your database layer
  • a mapping layer between the two
  • database-independent

So if you really need support for multiple databases (and not just SQL Server), or if you really need to be able to morph the database structure into a totally different object model - EF4 is a great place to start.

If you have a simple and straightforward little to medium-size app that only needs to be able to easily and quickly map tables 1:1 to objects, then I don't think EF4 comes even close in terms of simplicity and performance to Linq-to-SQL.

EF4 is great - and if you need its power - go with it!

But if your requirements are a lot less, it might just be overkill - continue to use Linq-to-SQL (I will) and be happy with it. I don't see any good reason to dump Linq-to-SQL - it's still totally available in .NET 4, has been blessed with some bug fixes and improvements even, and it will be around for at least another couple of years.

marc_s
Thanks, Mark, +1. I usually work with the simpler scenarios you outline, so your answer makes me believe I should stick with Linq-To-Sql unless/until I have more complex requirements.
DanM
When you say multiple databases you just talking about that it can do mysql or are you talking about if you need different types of databases hooked up in one EF? Also why is it called EF4 and not EF2.0 seems like a pretty stupid naming convention. Finally I see your point of going for simpler stuff but would it not be just safer to go with the EF as requirements are always changing and you might not need the advance features today but 2 years the road you might need it and then have to switch out the entire database layer?
chobo2
@chobo2: I mean EF4 can support multiple databases - you can connect to SQL Server, IBM DB2, MySQL and a few more. If you want to use them at once, you need to have multiple ObjectContexts of course - you can't mix several databases in a single ObjectContext. It's called EF4 because it's been released in the .NET 4 timeframe - but that's just marketing speak. Yes, it might be "safer" to go with EF4 right now - but I'm just saying, for now, in many cases, EF4 will be an overkill and hurt you in terms of performance and cause more headaches due to its complexity
marc_s
We have already released our implementations of EF v4 providers for Oracle, MySQL, PostgreSQL, and SQLite. We have also implemented a new product - LinqConnect - integrating our LINQ to SQL implementations for Oracle, MySQL, PostgreSQL, and SQLite. So, to be clear - you are not limited to SQL Server in case of LINQ to SQL development.
Devart
@Devart: that is great news and good to know - thanks!
marc_s
+1  A: 

@marc_s, @DanM:

Please do not consider this post as an advertisement :) We just want to know the opinion of advanced users of Linq to Sql.

We have implemented the following improvements in our LinqConnect (Linq to Sql Server, Oracle, MySql, PostgreSql, SQLite):

- Complex Type  
- Many to Many  
- Batch update operations  
- Recursive support in DataLoad options  
- Query level preload (like Include in EF)  
- TPT support (in LinqConnect 2.0)  

We also plan to add support for second level cache.

Are these improvements valuable for you?

Devart