Advice on replacing Enterprise Library Data Access Block by Entity Framework

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

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.

There is a number of EF providers for Oracle (Devart dotConnect for Oracle, DataDirect) and MySQL (Devart dotConnect for MySQL, MySQL Connector /NET), and Microsoft provides an Entity Framework provider for SQL Server, so there should not be any problems with database independence.

Is there any advantage to move to Entity Framework?

Generally quicker to get your data access work done. Linq syntax is great and can query sql.

Does EF will keep our non-dependent "Database Engine" criteria?

Not without some 3rd party support. Although I haven't run into ANY developers that in fact took a functioning application and switched database technologies to or from sql.

Or should we keep our EntLib DAAB implementation but upgrade to the latest version (5.0)?

DAAB is awesome!! I wrote a code generator for it.. Also after implementing EF for a large database with a VERY POOR relational schema I found that the EF 'wizard' took way to long to update, 3 min for 110 sql tables (approximately). It was too slow and I went back to DAAB... I will say the way forward is EF however. I just try use it with stored procedures and No Tracking for best performance. The other thing to be aware of with EF is merging conflicts when two people update entites separately. It can get confusing.