Problem
In the past, our development team decided to create a new enterprise application and decided to use "Linq to SQL" since the Entity Framework "sucked". (Not my opinion!) They used Visual Studio 2008 and the EF wasn't part of the default setup but required an additional add-in. So the decision was made to use Linq to SQL to access the database. As a result, we now have multiple projects around a datamodule class library containing a DBML and L2SQL entities...
Needed
It is now clear that those developers were wrong. Some moved on to other companies and a few new ones are included in this project. (Including me.) And we would like to use the Entity Framework instead. Preferably version 4 with .NET 4.0... This will allow us more flexibility with our data and we're hoping to include some inheritance in several of the entities, making开发者_运维问答 the code easier to read and nicer to use.
Question: How to...
So, how to migrate from "Linq to SQL" to the Entity Framework 4 without the need to rewrite much of our code?
Manually. There is no other way and if you don't have integration test suite for all projects using the data module you should not start with any migration until you write those tests because many linq queries which worked in Linq-to-Sql doesn't work in Linq-to-entities (and not only Linq queries).
Generally that migration is wrong idea. It looks like you want to make a migration just because you want to use another technology. What real business value will be added by this effort? EF and Linq-to-entities offers some additions but it is in many ways worse than Linq-to-sql. There is no need to touch code which works unless you have some real business requirement which will make this necessary. Especially migrating to EFv1 would be really stupid move. You can use .NET 4 with your current code without any problems because Linq-to-Sql is part of .NET 4 as well.
If you ask me the former developers made a good choice when they made selection between EFv1 and Linq-to-Sql.
精彩评论