Advice on replacing Enterprise Library Data Access Block by Entity Framework

Question

A few year ago, we developed a large ASP.Net application (C# / .net 3.5) that had to be "Database Engine" non-dependent (meaning this application could either use SQL Server, Oracle, MySQL ... as DB engine). For that, we used Enterprise Library Data Access Block 4.1.

But now, as we are on a "performance/scalability improvement" phase, we are thinking about technology upgrade or re-design of our application foundations.

So, the question is: is there any advantage to move to Entity Framework ? Does EF will keep our non-dependent "Database Engine" criteria ? Or should we keep our EntLib DAAB implementation but upgrade to the latest version (5.0) ?

Thanks

Answer 1

The biggest issue moving between them isn't about database independence, it's that the usage pattern is fundamentally different. The Data Access Block (DAAB) is primarily a convenience wrapper around ADO.NET. It makes it easier / less annoying to call stored procedures, but you're still dealing with datasets or data readers. It doesn't actually change how you're interacting with the database, it just makes it less annoying.

Entity Framework, on the other hand, is about data modelling and object-relational mapping. It works at a higher level than the DAAB does; you write your code in terms of your objects, not in terms of DataSets or DataReaders. It automates the "materialization" of the objects from the database so you don't need to write that code, maintains the relationships between them, etc. It's a much more fully featured, but quite different, way of working with the database.

You need to consider if you're going to move to the ORM style of data access first. From there you can decide if EF or one of the many other ORMs in the .NET space will suit your needs best.

There are lots of providers available for EF (see Devart's answer for a list) but they're all external / extra cost. The only one in the box is for Sql Server. Although I will add that DAAB doesn't actually completely cover the "database independence" thing - if you have any actual SQL in your DAAB calls, it doesn't help you with differences in SQL dialects. EF will.