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?

Improve this question
3
  • 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. Commented May 26, 2011 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. Commented May 26, 2011 at 15:13
  • Webster: thanks for looking it up and clarification Commented Jun 13, 2011 at 17:25

3 Answers 3

Reset to default
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.

Improve this answer
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.

Improve this answer
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

Improve this answer
3
  • and what do you use currently? Commented May 26, 2011 at 1:45
  • 2
    I think everyone is using linq2sql Commented May 26, 2011 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. Commented May 26, 2011 at 12:06

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.