views:

64

answers:

2

We are planning to migrate to .net 3.5 and evaluating Linq To SQL and Entity framework. Considering what people are saying every where on internet that EF 1.0 is buggy, complex, has suboptimal designer support etc, if we pick Linq to SQL - do you think we will be able to migrate it to EF 4 when the time comes?

The question arises because there may not be new features in L2S going ahead (it may not exist as some speculate) and we are not in position to skip 3.5 and directly jump to .net 4.0 for utilizing EF 4.

A: 

It will work, but don't become to dependent on L2Sql-features, build a repository or something other interchangeable layer that accesses your data, so you can put EF4 in it's place when the time comes!

sqlmetal is good for generating your model from sql, you will probably have less problems migrating to EF if you use something like it (sqlmetal, nhibernate, subsonic et al)

SilverSkin
A: 

LINQ-to-SQL will exist because it won't be removed from the framework, simply for backwards compatibility. It may not have new features, but if you application works without those features then it's not really a concern, is it?

You will be able to migrate to EF, but the amount of work involved could be hard to predict. What are you currently using as a data access layer and why are you changing?

Both LINQ-to-SQL and EF work by mapping regular .NET classes to database objects. The main difference is that EF can do more complex transformations, while LINQ-to-SQL requires that the classes match the tables almost exactly.

If you want to (eventually) rewrite your data layer in EF4, then I'd suggest keeping whatever you have now until you're ready to rewrite. It doesn't make sense to rewrite 3.5 now and then rewrite again in a year or two. What would be the benefit?

Kirk Broadhurst