Why entity framework use over ado.net.

Sign in to answer this question.

• 

  Manikandan Murugesan9y agoPosted Jun 9, 2017, 11:35 AM

  Accepted answer

     

      I suggest you to go with the Entity Framework(EF) because EF is an object-relational mapper that allows the developers to interact with the relational data using the domain-space objects.It works on the top on the ADO.NET by handling the ADO.NET provider. 

     For Further Reference visit: https://stackoverflow.com/questions/27270124/entity-framework-vs-ado-net

   

      The ADO.NET provides the dataset, datatables, command, and connection objects.It allows you to work on the higher level objects such as managers,workers,suppliers etc..

       

          The ADO.NET provides the set of software components that the developer can use access data and various data services in the database.

   

     For performance reference visit : https://stackoverflow.com/questions/15107992/performance-analyze-ado-net-and-entity-framework

   

        For your large domain project i suggest to go with the Entity Framework.Start your project as your mind wish.
• NA

  Navneet Arora8y agoPosted May 22, 2018, 11:07 PM

  Some benefits of Entity framework are:

  • Simplification of Queries.
  • Easy to implement CRUD operations.
  • The models can be represented in a better way.
  • Easy to manage relationships between tables.

  One more thing If you know that your developers are not comfortable in writing SQL Queries you can go for EF as well.
• 

  Manikandan Murugesan9y agoPosted Jun 12, 2017, 2:41 AM

  I faced a similar situation where we had a large database with many tables 7- 10 million records each. we used Entity framework to display the data. To get nice performance here's what I learned; My 10 Golden rules for Entity Framework:

  1. Understand that call to database made only when the actual records are required. all the operations are just used to make the query (SQL) so try to fetch only a piece of data rather then requesting a large number of records. Trim the fetch size as much as possible

  2. Yes, (In some cases stored procedures are a better choice, they are not that evil as some make you believe), you should use stored procedures where necessary. Import them into your model and have function imports for them. You can also call them directly ExecuteStoreCommand(), ExecuteStoreQuery<>(). Same goes for functions and views but EF has a really odd way of calling functions "SELECT dbo.blah(@id)".

  3. EF performs slower when it has to populate an Entity with deep hierarchy. be extremely careful with entities with deep hierarchy

  4. Sometimes when you are requesting records and you are not required to modify them you should tell EF not to watch the property changes (AutoDetectChanges). that way record retrieval is much faster

  5. Indexing of database is good but in case of EF it becomes very important. The columns you use for retrieval and sorting should be properly indexed.

  6. When you model is large, VS2010/VS2012 Model designer gets real crazy. so break your model into medium sized models. There is a limitation that the Entities from different models cannot be shared even though they may be pointing to the same table in the database.

  7. When you have to make changes in the same entity at different places, use the same entity, make changes and save it only once. The point is to AVOID retrieving the same record, make changes & save it multiple times. (Real performance gain tip).

  8. When you need the info in only one or two columns try not to fetch the full entity. you can either execute your sql directly or have a mini entity something. You may need to cache some frequently used data in your application also.

  9. Transactions are slow. be careful with them.

  10. SQL Profiler or any query profiler is your friend. Run it when developing your application to see what does EF sends to database. When you perform a join using LINQ or Lambda expression in ur application, EF usually generates a Select-Where-In-Select style query which may not always perform well. If u find any such case, roll up ur sleeves, perform the join on DB and have EF retrieve results. (I forgot this one, the most important one!)

  if you keep these things in mind EF should give almost similar performance as plain ADO.NET if not the same.
• 

  Manikandan Murugesan9y agoPosted Jun 12, 2017, 2:35 AM

  Hello Amit ,

  EF is completely fine for high-traffic/high-performance applications, just like every other framework is fine for high-traffic/high-performance applications.

  For more details refer this link : https://softwareengineering.stackexchange.com/questions/117357/is-entity-framework-suitable-for-high-traffic-websites/117360

   

  this link too : https://stackoverflow.com/questions/4946561/is-entity-framework-good-for-bigger-database

   

  Thanks Amit.
• AS

  amit shukla9y agoPosted Jun 12, 2017, 2:17 AM

  Hi Manikandan,

   

  Thank you for your response.

   

  I have read many articles but most of article suggested me, when you are handling large 

  database (i.e above 1000 tables) then entity framework is not situable for that.

  So Plz give me any solid resason for why use entity for large database.

   

  Thanks!

  Amit