Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

The development team I'm working with will be moving to .NET 4.0 soon, however, the data access class library we use still uses ADO.NET "classic", meaning SqlDataReader, DataTable, and the like. Meanwhile, it seems like Microsoft and probably the rest of the world is moving forward with Entity Framework and WCF Data Services. I didn't find anything on MSDN that indicated which of the data access technologies Microsoft considers best practices.

Does Microsoft have a preference? What data access are most people using currently? Are there good reasons to stay with ADO.NET classic and not move to Entity Framework?

share|improve this question
+1 for "and reality" – Steven A. Lowe May 26 '11 at 1:45
Good question. One nit: "data layer" may be a more precise term. "Tiers" can also mean parts of a distributed system runnable on separate boxes. – azheglov May 26 '11 at 13:34
@azheglov, "data layer" was my first thought, but then I looked at this and I figured to go with whatever terminology I saw on MSDN: I'd agree that data layer is more precise though. – T. Webster May 26 '11 at 15:13
Webster: thanks for looking it up and clarification – azheglov Jun 13 '11 at 17:25
up vote 4 down vote accepted

In my firm we are using the EF. It's a nice ORM, suitable for our small project. In reality people are using EF or NHibernate. Both frameworks are good. EF has a great MS support and you can find great tools bundled with Visual Studio. NHibernate is considered better than EF but there is a bigger "learning curve" so you will spend more time adopting it.

I think that, if you are on the Ado.Net "classic" try the EF. Create a simple project and replace some of the DAL methods. Check how it works and how you can manage/modify the code. Compare it with the simple "SqlDataReader" methods and decide which is better. Remember that every technology shift needs some time for adoption so you have to calculate if this change will be beneficial for your company in the long run.

share|improve this answer

My team is finding the reality of moving to EF a bit of a pain. It's not because EF is bad or not useful, but the scope of converting our existing data layers (fairly massive) from strongly typed datasets originating from ADO.Net framework 2.0 over to EF is just a lot of intensive work that doesn't really gain us anything. For new stuff we are still fairly torn because we all have opinions and goals. For our Silverlight projects, we are focusing solely on EF and RIA services, but for web projects (webforms and MVC 3) we are using Linq2Sql primarily.

We are finding fewer headaches and faster development using Linq2Sql, but I know Microsoft is pushing the EF agenda (particularly with WCF and RIA services). Linq2Sql isn't going anywhere, but all the new toys and cool features will be focused into EF. I'd say if you have a choice early on, EF would be a good place to start. If you're already mid stream, I don't know that it'll be very easy to switch over.

share|improve this answer

Entity Framework is the preferred way to go. LinqToSql will be supported and maintained but the development focus going forward is on Entity Framework. Choosing between ADO.NET Entity Framework and LINQ to SQL

share|improve this answer
and what do you use currently? – T. Webster May 26 '11 at 1:45
I think everyone is using linq2sql – Cynede May 26 '11 at 5:38
@nCdy: While some members of our team have decried Linq2Sql as being too "chatty", we are all of the opinion that EF auto-generates too much unnecessary junk that L2S just bypasses. – Joel Etherton May 26 '11 at 12:06

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.