c# - Entity Framework VS pure Ado.Net

Question

EF is so widely used staff but I don't realize how I should use it. I met a lot of issues with EF on different projects with different approaches. So some questions brought together in my head. And answers leads me to use pure ado.net with stored procedures.

So the questions are:

1. How to deal with EF in n-tier application?
   For example, we have some DAL with EF. I saw a lot of articles and projects that used repository, unit of work patterns as some kind of abstraction for EF. I think such approach kills most of benefits that increase development speed and leads to few things:

   • remapping of EF load results in some DTO that kills performance(call some select to get table data - first loop, second loop - map results to some composite type generated by ef, next - filter mapped data using linq and, at last, map it to some DTO). Exactly remapping to DTO is killer of one of the biggest efs benefit;
     or
   • leads to strong cohesion between EF (and it's version) and app. It will be something like 2-tier app with dal and presentation with bll or dal with bll and presentation. I guess it's not best practice. And the same loading process as we have for previous thing except mapping, so again performance issue raised up. We could try to use EF as DAL without any abstraction under them. But we will get similar issues in some other way.

2. Should I use one context per apphreadatomic operation? Using approach - one context per apphread may slightly increase performance and possibilities to call navigation properties, but we meet another problem - updating this context and growing loaded data in context, also I'm not sure about concurrency with one dbcontext per apphread. Using context per operation will lead us to remapping EF results to our DTO's. So you see that we again pushed back to question no.1.

3. Could we try to use EF + stored procedures only? Again we have issues from previous questions. What is the reason to use EF if the biggest part of functionality will not be used?

So, yes EF is great to start project. It so convenient when we have few screens and crud operations.

But what next?

All this text is just unsorted thoughts. I know that pure ado.net will lead to another kind of challenges.

So, what is your opinion about this topic?

Answer 1

By following the naming conventions , you will find it's called : ADO.NET Entity Framework , which means that Entity Framework sits on top of ADO.NET so it can't be faster , It may perform both in equal time , but let's look at EF provides :

• You will no more get stuck with writing queries without any clue about if what you're writing is going to compile or not .
• It makes you rely on C# or your favorite .NET language on writing your own data constraints that you wish to accept from the target user directly inside your model classes .

Finally : EF and LINQ give a lot of power in maintaining your applications later .

There are three different models with the Entity Framework : Model First , Database First and Code First get to know each of 'em .

-The Point about killing performance when remapping is on process , it's because that on the first run , EF loads metadata into memory and that takes time as it builds in-memory representation of model from edmx file.