13

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?

  • 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
  • 1
    @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: msdn.microsoft.com/en-us/library/bb384398.aspx. 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
4

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.

5

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.

3

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

  • and what do you use currently? – T. Webster May 26 '11 at 1:45
  • 2
    I think everyone is using linq2sql – cnd 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 clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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