LINQ to SQL or classic ADO.NET?

I am asking my self many times before start writing a new app or data access library , should I use LINQ to SQL or classic ADO.net , I have used both and the development time I spend on building an app with LINQ to SQL is like the 1/3 compared to ADO.net.

The only think I like using LINQ to SQL is that I don't have to design the domain objects LINQ does that for me and saves me from spend my time on boring things :P But is LINQ to SQL suitable for large scale proj开发者_高级运维ects, is there an overhead that we can avoid when using ADO.net ?

Personally I wouldn't go back to ADO.NET for DAL stuff. However, remember that with Linq2Sql you are tied to MS SQL Server, which I think is unacceptable.

Maybe also consider other DALs/ORMs such as NHibernate, SubSonic, Entity Framework (MS), LightSpeed, Castle ActiveRecord (NHibernate based). Some of these (e.g. NHibernate and Entity Framework) also have optional Linq query interfaces.

I love LINQ to SQL; it's easy to work with your data model. If you have .NET 4, consider using ADO.NET Entity Framework, as its the future and it supports multiple databases.

There is a slight overhead with LINQ to SQL if you use LINQ queries against your database, but I think its negligible in most respects. We have had good performance. Additionally, it supports stored procedures, so you always have that to fall back to from a performance perspective.

If it takes you 1/3 as long to write the LINQ-to-SQL version, that leaves you with 2/3 of the original time freed up for other stuff, like performance tuning.

We're a $2.5B solar company, and we've used L2S as a foundation for all of our manufacturing operations applications. We have no regrets. One huge plus for us is that all our queries use LINQ. This means all our queries are strongly typed. So, after a schema change, the compiler will tell us which of our queries need fixing. Of course, if you channel all your queries through to stored procedures, you don't have this benefit.

LINQ to SQL may be useful in a development environment which is tied to Microsoft in a significant way, and there is no foreseeable deviation from Microsoft in the next few years. However, for extensibility to other DBMS environments, I would recommend Entity Framework over LINQ to SQL, with the caveat that the 2008 version still has some annoying limitations (not sure about 2010 yet).

I would never use ADO.NET directly if I can help it. This is mainly because as a developer, it's in my best interest to take on tools which can be applied in multiple areas. I currently use LINQ to Entities and Entity Framework to communicate with an Oracle database. LINQ to SQL wouldn't work for this.

See this. If you're saving time, and making your work easier, is it worth it? Unless you know of specific problems you could solve by hand-coding your data access, I wouldn't bother.

There is no reason whatsoever to ADO.NET over Linq to SQL