I've been investigating what data layer to use for a new web-based project I'm designing and I'm very keen to look at incorporating LINQ to SQL. Its apparent simplicity, flexibility and designer support really appeals and the implicit tie-in to SQL Server is fine.
However, it has been announced recently that LINQ to SQL will be taking a back seat to the Entity Framework now that it's been passed to the ADO.NET team (http://blogs.msdn.com/adonet/archive/2008/10/29/update-on-linq-to-sql-and-linq-to-entities-roadmap.aspx). Sure, it will be supported in the future, but it's unlikely that it will see much more development work.
With this in mind, would you recommend me using this technology for my project or is it worth either selecting an alternative ORM (nHibernate?) or manually coding up a generic DAL?
The project itself is ASP.NET and SQL Server 2005/2008 based and will possibly use MVC, even though it's still in beta. It's a personal project, the database won't be overly complex and it will mainly be used as a prototype to look at .NET future tech. I would be basing future projects on what I learn from this one though, so the choices I make will affect larger solutions to come.
And yes, I realise that Microsoft will probably bring out a whole new data access technology tomorrow anyway! ;)
Well, it's mostly covered in answers here (some interesting points of view as well) already, but I'm going to say it again anyway..
LINQ to SQL (L2S) is very versatile, but it feels a tad too basic from my viewpoint. In most cases it does a good job at doing simple things, but as soon as you ask a little more of it, it gets expensive. This isn't at all a bad thing. I actually think LINQ to SQL actually suppliments the Entity Framework nicely.
Take Auto Paging with LinqDataSource for example. If you don't specify Order By/Group By then it's quite economical. Throw ordering or grouping into the mix and you start to get a spike in performance (becomes very chatty). You then pretty much have to write your own paging implementation (which isn't terribly hard, I'll admit).
I'll be the first to admit that L2S has the advantage over the Entity Framework in terms of the quality of the generated T-SQL (I should, since L2S is specifically built for querying SQL Server) and conceptually and symantically, much of LINQ to SQL is similar to EF, but where you hit the wall is on expanding needs and consideration for more complicated implementation requirements.
If I were to start from scratch and choose to devote personal development time, I'd pick the Entity Framework. Interestingly enough, I'm working on a project at the moment which uses L2S and it is being designed to scale nad handle heavy loads, but when we hit some of the more "creative" requirements, we are often forced to expand on SQL Metal (e.g. many-to-many relationships).
So.. in short.. I'd approach it thus:
a) learn LINQ to SQL as an intro (to Microsoft's ORM patterns and technology).. it gets you familiar with most of the fundamentals which are shared with the Entity Framework, and a taste of LINQ style querying (an acquired taste if you have a background in T-SQL)
b) once you've got a handle on LINQ to SQL, I'd recommend jumping over to the Entity Framework to learn the additional benefits (eSQL etc)
c) Implement a proof of concept project in both and compare the results.