Hi Mike,
Thanks for your feedback.
Please allow me to ask for one more advice:
I'm also eagerly reading your articles / tutorials on mikesdotnetting.com and found your tutorial about integration of Entity Framework with ASP.NET Web Pages.
In fact, I've tried many different frameworks and languages and were very happy with ORM tools. However, I've made a little benchmark test based on SQL CE database and learned much to my surprise that access via Database helper is essentially faster than access via EF.
My results:
Write operations, each 1000 datasets
Entity Framework with Web Pages (SQL CE) [in ms]
EF test1: 2440 - 4623 - 6662
EF test2: 2609 - 4491 - 6621
EF test3: 2392 - 4725 - 7007
---------------------------------------------
SQL(Database.Open) with Web Pages (SQL CE) [in ms]
DB test1: 136 - 152 - 162
DB test2: 151 - 161 - 142
DB test3: 160 - 167 - 177
Read Operations, each 10000 datasets [in ms]
EF: 192 - 238 - 228
------------------------------
DB: 79 - 84 - 80 [normal Database method]
------------------------------
DBs: 121 - 94 - 100 [StronglyTyped from Jeremy Skinner]
Do you think that this performance difference could be realistic? I would really like to show the code of the test but I deleted it by mistake.
Many people think that such tests are not very meaningful based on "real" apps/websites. What do you think? And what method do you prefer: Database helper, EF or raw ADO.NET?
Sorry for so many nerving questions
Regards from Germany
Marcus
Quote:
Originally Posted by Mike Brind
Hi,
Thanks for your comments about the book.
If you use the Database.Open method, the Web Pages framework calls the Close method at the end of the request. If you use ADO.NET code, you are always advised to create connections in a using block or to ensure that you call Close when you are done.
There is nothing stopping you from calling Database.Open in a using block. It's just that it is not necessary to do so.
There is a slightly different issue when it comes to SQL Compact. That particular database runs in the same process as the ASP.NET app, so you don't have to worry about unmanaged resources draining memory like connections to out-of-process resources (SQL Server, Access, MySQL etc) would.
|