Version 6 - DAAB or EF?

Topics: Data Access Application Block
Apr 27, 2013 at 10:27 AM
Hi there,

I haven't used DAAB for ages and I thought it was dead since EF since to be the way to go. Now, with the version 6 I see DAAB coming back and looking into the code I don;t see any reference to EF.
I haven't had the time yet to play with the latest version of DAAB but my question is, is it worst it or should I keep on using EF? (version 6 of EF since to be everything I need).

Thanks
Editor
Apr 29, 2013 at 5:55 PM
The Data Access Application Block has been around since day one and continues to be supported so news of its death are greatly exaggerated. That said, the block is pretty much still what it always has been -- a relatively (these days) low level abstraction over ADO.NET. Features have been added to make the block more useful such as Accesors.

Despite the addition of accesors the DAAB is not an ORM and is not intended to be a replacement or competitor to Entity Framework. So, if anyone wishes the functionality present in an ORM then you should use an ORM such as Entity Framework. If you are currently using Entity Framework then I can't think of a compelling reason to change approach and switch to using the DAAB.

However, feel free to take a look at some of the cool new Enterprise Library 6 features such as Semantic Logging. :)

~~
Randy Levy
entlib.support@live.com
Enterprise Library support engineer
Support How-to
Apr 30, 2013 at 12:45 AM
Hi Randy,

Thank you very much for that answer and thanks to Grigori Melnik that has been answering me on Twitter as well.
Your answer is more than clear and I'll be checking out the Semantic Logging.

My concern was that I'm expending a lot of time converting some app from EF Database First to EF Code First and, since every time you release something new is something REALLY COOL, I just wanted to confirmed that I'm not taking the wrong path.

Thanks again,
Apr 30, 2013 at 1:55 AM
Just to share my thoughts on the DAAB.

I don't think using the DAAB makes a system look uncool because I have many times explored EF and decided to go back to DAAB due to one very important reason - PERFORMANCE. My systems are part of a telco ecosystem and it requires to service millions of requests a day and EF just couldn't cut it. Don't get me wrong, EF doesn't fail in the environment but it is just processing too slowly as compared to DAAB.

Every transaction being processed is considered revenue to the company and so if I shift to EF, my transactions per minute will be greatly reduced and thus my company will be losing a lot of money by the hour.

I also find the DAAB more straight-forward if the DBA requires us to perform some 'crazy acrobatics' on our SQL :) Therefore, I really appreciate P&P's effort in keeping the DAAB alive.

Hugs,
Serena
Jul 31, 2013 at 4:49 AM
Will EF 6.0 with Async/Await features improved the performance?
Editor
Aug 1, 2013 at 1:03 AM
An Entity Framework forum would probably be a better place to ask about EF performance. My answer would be that it probably depends on the specific scenario. Given a more specific scenario I would say that it would make sense to measure the actual performance against your goals (e.g. processing time or transactions per second, etc.) to see what the impact is.

~~
Randy Levy
entlib.support@live.com
Enterprise Library support engineer
Support How-to
Feb 12 at 5:19 PM
@randylevy

You as EntLib support engineer may have some benchmark using DAAB and EF (latest version) to show us ?

Thank you!
Editor
Feb 16 at 6:34 AM
There are some performance articles available on the web. The data access application block is basically a wrapper around ADO.NET (a slight simplification but mostly true). In general, raw SQL (using ADO.NET) will not be slower than Entity Framework (or any ORM) but an ORM provides benefits that make them attractive options in many projects. But actual performance will depend to a large degree on the specifics involved. e.g. table structure, table size, types of queries, features used, application design, etc.

~~
Randy Levy
entlib.support@live.com
Enterprise Library support engineer
Support How-to