33

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 app\thread\atomic operation? Using approach - one context per app\thread 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 app\thread. 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?

marc_s
  • 732,580
  • 175
  • 1,330
  • 1,459
Crossman
  • 815
  • 3
  • 9
  • 16

4 Answers4

21

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.

  • In n-layer app you have to remap EF results into some other classes (DTO or own POCO or something else) because presentation layer doesn't know about data access layer, so you haven't this quite convenient auto-generated classes in your view564model. And that's why I made assumption that when you call a DbSet<> it makes call to DB with some kind of query, and I doubt that it's optimized by server as, for example, sp is. Next ef gets result and perform mapping into auto-generated class. You get this result in your business logic layer, filter it in some way(using linq .Where for example)... – Crossman Mar 11 '14 at 17:10
  • ... and remap in your persistence object. Then you make same operations on this objects and send final result to presentation layer. So i'm telling you that this operation reduce ef usefulness. For example you have table 100 000 records and you load all of this records and do all steps that I have described. – Crossman Mar 11 '14 at 17:12
  • 1
    EF fetches only necessary records and queries are transformed into proper SQL statements. EF can cache objects locally within DataContext (and track all changes made to entities), but as long as you follow the rule to keep context open only when needed, it won't be a problem. –  Mar 11 '14 at 17:27
  • 1
    I even don't think about executing string queries (some thing like DBContext.ExecuteQuery("select * from [tablename] where [fieldname] > 10)"). It's not a variant at all. – Crossman Mar 11 '14 at 17:30
  • 1
    if you frequently have to work with large amounts of data that perhaps EF is not for you. But usually simple applications only deal with a small amount of records at a time. Even if you have some function to "Show ALL records" to the user, you would implement paging so that you don't display all 100 000 records at once! – failedprogramming Mar 12 '14 at 01:05
  • Can you elaborate on the 3 models "Model First , Database First and Code First"? I'm fairly new to EF but when creating a new EF item it has **EF Designer** (empty or from db) and **Code First** (again empty or from db). From that I assume there is only "Model First" or "Code First" and that you could use a database to start off the project, but that wouldn't affect long-term development? – Zorgarath Jun 21 '17 at 13:20
  • 1
    For simple apps easier everything to do manually (EF is too heavy), but for large data it looks like EF is not efficient enough. Conclusion: there is no significant reason to use EF at all. – Vlad Gonchar Sep 09 '19 at 20:02
1

ADO. Net is an object oriented framework that allows you to interact with database system (SQL, Oracle, etc). Entity framework is a techniques of manipulating data in databases like (collection of queries (inert table name , select * from like this )). it is uses with LINQ.

Zeeshan Haider
  • 87
  • 6
1

Entity Framework is not efficient in any case as in most tools or toolboxes designed to achieve 'faster' results.

  1. Access to database should be viewed as a separate tier using store procedures as the interface. There is no reason for any application to have more than absolutely require CRUD operations. Less is more principle. Stored procedures are easy to write, secure, maintain and is de facto fastest way. It's easy to write tools to generate desired codes for POCO and DbContext through stored procedures.

  2. Application well designed should have a limited numbers of connection strings to database and none of which should be the all mighty God. Using schema to support connection rights.

  3. Lazy loading are false statements added to solve a problem that should never exist and introduced with ORM and its plug and play features. Data should only be read when needed. Developers should be responsible to implement this logic base on application context.

  4. If your application logic has a problem to maintain states, no tool will help. It will in fact, make it worse by cover up the real problem until it's too late.

  5. Database first is the only solution for a well designed application. Civilization realized long time ago the important of solid aqueduct and sewer system. High level code can and will be replaced anytime but data stays. Rewrite an entire application is matter of days if database is well designed.

  6. Applications are just glorified database access. Still true in most cases.

This is my conclusion after many years in business applications debugging through codes produced by many different tools or toolboxes. The faster results advertised are not even close to cover the amount of time/energy wasted later trying to clean up the mess. Performance issues are rarely if not ever caused by high demand but the sum of all 'features' added through unusable tools.

marc_s
  • 732,580
  • 175
  • 1,330
  • 1,459
Tien Nguyen
  • 19
  • 1
0

ADO.NET provides consistent access to data sources such as SQL Server and XML, and to data sources exposed through OLE DB and ODBC. Data-sharing consumer applications can use ADO.NET to connect to these data sources and retrieve, handle, and update the data that they contain.

Entity Framework 6 (EF6) is a tried and tested object-relational mapper (O/RM) for .NET with many years of feature development and stabilization. An ORM like EF has the following advantage

  • ORM lets developers focus on the business logic of the application thereby facilitating huge reduction in code.

  • It eliminates the need for repetitive SQL code and provides many benefits to development speed.

  • Prevents writing manual SQL queries; & many more..

  1. In an n-tier application,it depends on the amount of data your application is handling and your database is managing. According to my knowledge DTO's don't kill performance. They are data container for moving data between layers and are only used to pass data and does not contain any business logic. They are mostly used in service classes.See DTO.
  2. One DBContext is always a best practice.
  3. There is no such combination of EF + SP(Stored Procedure) as per my knowledge. If you wish to use an ORM like EF and an SP at the same time try micro-ORMs like Dapper,BLToolkit, etc..It was build for that purpose and is heck lotta fast than EF. Here is a good article on Dapper ORM.

Here is a related thread on a similar topic: What is the difference between an orm and ADO.net?

Community
  • 1
  • 1
Tahir77667
  • 2,290
  • 20
  • 16