With EF you get a mapping layer (i.e. your entities) between your class objects and your database tables. If you need that kind of flexibility, or prefer a domain-driven design model (as opposed to a table-driven design), EF might be worth considering. Linq to SQL is pretty much a class-to-table mapper.
Well, at the end depends on requisites.
Now you uses linqtosql and it is right for you, but maybe one day you have more sophisticated requisites that you can better complish with EF. For instance using velocity or whatever.
I've often wondered this myself as EF seems to add a lot of complexity over L2S. Since MS is actively developing EF, there are some new aspects of EF 4 that may be worth checking out. There is a nice summary on the ADO.NET team blog that describes how the API for EF is evolving to support a wider range of development patterns.
In particular, I'm personally interested in support for POCO and the repository pattern as they are a nice fit for the projects I work on. In my opinion, one compelling reason to use any particular provider is how easy it will be to switch to a completely different provider in the future (without overhauling all of your application code, of course). I find L2S lacking in this respect (out of the box, anyways), and I'm happy to see the changes in EF 4. So far, however, I have only been reading about these changes in EF 4, so I can't say how well they actually work in practice.
I asked myself this question when I first saw EF and I'd already written a large application in Linq2Sql. The biggest change is done in the object mapping layer. In EF relationships and navigation is managed for you. So if I have two tables that have a foreign key relationship (say Pets and Owners) I can do
pet.owner
whereas in L2S I'd have to write the join query myself. Many-to-many mappings are handled sweetly in that if you have a 'pure join table' (that is a table with the two foreign keys and no other data) then this table is not represented in the object mappings.
You can also handle eager/lazy loading yourself.
I can also develop in POCOs so I'm not tied to the framework directly i.e. I don't have all the noise of the L2S or the EF types getting in the way, this makes testing way easier.
Overall I much prefer EF but YMMV
Entity Framework has better compatibility if you expect your application to scale on other DBMS, that's one of it's main advantage.
Entity Framework will work on DBMS other than Microsoft SQL Server, like Oracle, MySQL etc.
While Linq is limited to MS SQL Server.
L2S allows for implicit lazy loading while the EF has explicit lazy loading. In a small project the implicit work done in L2S is certainly nice and good for rapid development & changes to the model but in larger projects, developers may want more control over what database resources the app is calling.
See http://www.singingeels.com/Articles/Entity_Framework_and_Lazy_Loading.aspx
EF is geared to be an all out ORM where your object model is significantly different then your DB schema. L2S is more aimed at being a quick DAL generator.
The problem is that EF is a mediocre ORM, while L2S is a really great DAL generator.
I would say if L2S fits your needs, stay with it and don't let MS marketing push you around. If L2S doesn't do what you need it to do, and you need to stay in microsoft products, go with EF. If you have a bit of freedom over your technology, look into NHibernate and LLBGen (imo both are better then EF)
I made the switch from Linq2Sql to Entity Framework some time ago for all my projects. Initially it was a step backward in several regards - date expressions that worked just fine in Linq2Sql didn't work in EF and there was no lazy loading option. But now, with Entity Framework 4 everything works smoothly.
If it's just you and you don't have time to learn EF, stick with Linq2Sql. But if you do have time and think you might eventually want other forms of inheritance than -per-table, or any of the other features of EF, go for it!
And the #1 reason you should make the switch: Entity Framework experience will look good on your resume!
They are both very buggy. I've found 8 bugs in Entity Framework since I started using it a month ago (two affect L2S, at least three are still present in EF4). It has been one of the most painful experiences of my life.
The separation of classes and tables would be really nice, though, if EF worked the way they wanted it to.
I big reason not to use Linq2SQL is that it has a significant implcit design flaw:
The recommended best practice for using a DataContext is that it be used in a short lived "unit of work" style. Great, except that it's a moderately expensive object to keep creating and disposing of in the first place.
The snag comes in when you want to deserialize or recreate an object (perhaps, from a submitted web page) and then update an existing record. The Attach method offered by the Linq-to-sql will only accept the following three scenarios:
The first scenario requries database changes, which for some environments is unacceptable. The second scenario is down-right inefficient - why retrieve data you already have? The third scenario is un-realistic - stateless web apps don't typically retain historic information.
The point here is... EF4.0 allows you to reattach an object to an ObjectContext and mark it as added or new, and the context will generate the correct INSERT/UPDATE statement accordingly.