none
Best ADO.NET based Data layer as Entity Framework is not proving to be High Performance RRS feed

  • Question

  • Hello All, 

    i am working on designing and choosing libraries/tools for an application and reach at point where i need to choose between a ADO.NET based library like SQL Helper or Entity Framework(6/Core). 

    people in my organisation are facing performance issues with Entity Framework 6 and core( core is having little better than 6). 

    I want to know if there best/Good library or Tool available for .NET to communicate with SQL Server 2008 R2 and onwards.

    i know there are tuning suggested for entity framework and its has  some other advantages while in development, but i believe (may be need to learn more) that its good to save time and effort while developing application but if one fails to deliver a performing app than there is no point in saving time and effort in development. it would be better that we take more time and deliver good high performing Application.

    please help me .

    thank you

    Dheeraj Kumar 


    Thank you Dheeraj Kumar


    • Edited by Kumar Dheeraj Monday, February 4, 2019 2:54 PM spelling corrections
    Monday, February 4, 2019 2:53 PM

All replies

  • Hi Kumar Dheeraj,

    As far as I know, entity framework is based on ado.net, but if develop an application which has a lot of single-entity operations (CRUD) , I would suggest that you could pick entity framework, which has equivalent performance with ado.net, if it is a reporter application with big bulk operations, ado.net is a good choice. 

    And here is an excellent thread about how to choose ado.net and entity framework, which is analyzing from the following aspects. 

    1) Performance

    2) Speed of Development

    3) Neat/Maintainable code

    4) Flexibility

    5) Overall

    https://stackoverflow.com/questions/2698151/entity-framework-vs-linq-to-sql-vs-ado-net-with-stored-procedures

    In addition, about entity framework performance, here is a document for your reference.

    https://docs.microsoft.com/en-us/dotnet/framework/data/adonet/ef/performance-considerations

    Best regards,

    Zhanglong


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Tuesday, February 5, 2019 1:37 AM
    Moderator
  • Hi Dheeraj,

    I have always "rolled my own" DataAccess, not wishing to rely on the "baked-in" stuff that has a lot of overhead that I didn't need. So, what follows is my own stuff and I think you can probably learn from it and write your own DataAccess "Framework".

    I've written lots of blog posts about various aspects of the subject of DataAccess. I call the following links "The Works", because it delves into lots of elements relating to Data (after all, an application would be nothing without it's Data). From DataAccess to DataSets to DataBinding (all my DataBinding posts deal only with Windows Forms).
     
    First, let me say that DataAccess should never be included directly in the UI. See my blog post about Multi-tier applications:
     
    http://geek-goddess-bonnie.blogspot.com/2010/10/multi-tier-applications.html
     
    In the above blog post, I also have links to my 3-part DataAccess series, which I'll go ahead and include here also.
     
    First, check out my 3-part series on Data Access for some basic ideas. I'm using a SQL database, but the same would apply to other databases (except you'd use OleDb classes instead of Sql classes):
     
    http://geek-goddess-bonnie.blogspot.com/2009/09/dataaccess-part-i.html
    http://geek-goddess-bonnie.blogspot.com/2009/10/dataaccess-part-ii.html
    http://geek-goddess-bonnie.blogspot.com/2009/10/dataaccess-part-iii.html
     
    Each post adds extra complexity to the Data Access classes, but more flexibility. The first post is enough to get you going in the right direction and give you a general idea of the concept, but the second post is more useful. The third post has a more complete example class, but it gets into using anonymous delegates and may be too much (which, to be honest, I don't use the anonymous delegates anymore, but I used to on previous projects several years ago). However, even if you don't want to use the anonymous delegate approach, the more complete example class should show you how to save data, which the examples in the first two posts don't do.
     
    Those 3 posts are old, I wrote them back in 2009. They are still relevant, but I needed to add two things: implementing IDisposable and using TransactionScope for transactions. So, I added this post to my Data Access series:
     
    http://geek-goddess-bonnie.blogspot.com/2015/06/dataaccess-revisiting-yet-again.html
     
    Several of my readers have gotten back to me with some questions about this code and I realized that I'm still missing a few important items, such as DataAdapter.TableMappings!! So, I finally wrote a new post about that:
     
    http://geek-goddess-bonnie.blogspot.com/2016/08/more-dataaccess-and-you-thought-i-was.html
     
    One more post should be mentioned when talking about DataAccess, and that is the use of Stored Procedures. This is my most recent post and besides showing you a sample Stored Proc (for inserting or updating, both in the same Proc), I also show you how to call it (within my DataAccess class "framework") and a bonus: the code to automatically generate "CREATE PROCEDURE" SQL code which you can use to include in your own database utility application (or a start on writing such a utility if you don't have one).

    https://geek-goddess-bonnie.blogspot.com/2018/01/use-and-generate-put-stored-procedures.html

    I always use Typed DataSets and do *not* use TableAdapters ... so, here's a post I have about creating Typed DataSets without TableAdapters being generated.I know that DataSets have gotten a "bum rap" lately since lots of people prefer using Entity Framework, LINQ to SQL and similar types of ORMs. But I find Typed DataSets to be quite simple to use (especially when you avoid the TableAdapters):
     
    http://geek-goddess-bonnie.blogspot.com/2010/04/create-xsd.html
     
    Speaking of my dislike for TableAdapters, part of the reason is because, early on when they were first introduced, all the generated code "lived" in the same project (and even in the same generated files!). This doesn't bode well for separation of concerns, because you couldn't separate your Typed DataSet (basically a business/data entity) from the DataAccess tier!  A big no-no!  But, if you insist on using them, here is an MSDN article about how to separate your DataSets from their TableAdapters (putting them in different projects):
     
    https://msdn.microsoft.com/en-us/library/bb384586(v=vs.140).aspx
     
    You'll also want to be aware of this little "gotcha" that sometimes happens with the MSDataSetGenerator:
     
    http://geek-goddess-bonnie.blogspot.com/2012/08/msdatasetgenerator-gone-wild.html 

    And lastly, a few posts about Databinding (these two searches have a few overlapping posts):
     
    https://geek-goddess-bonnie.blogspot.com/search?q=BindingSource
    https://geek-goddess-bonnie.blogspot.com/search?q=databind
     
    I hope these help and give you some ideas.



    ~~Bonnie DeWitt [C# MVP]

    http://geek-goddess-bonnie.blogspot.com

    Tuesday, February 5, 2019 1:51 AM