Traditional sql approach VS ORM [closed]

Question

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 4 years ago.

I am really frustrated of searching this answer that what is better - Traditional System.Data.SqlClient approach or using any ORM like EF or Dapper I have seen many comparisons through many links, some are :

1. https://github.com/StackExchange/dapper-dot-net

   

2. http://www.dontpaniclabs.com/blog/post/2014/05/01/speed-comparison-dapper-vs-entity-framework/

3. ORM vs traditional database query, which are their fields?

One thing that I can understand that, hand written traditional sql code is better in performance than any other approach. but it is still hitting in my mind that if we already had the best approach then why ORMs?

Is it only because we want to reduce DataLayer code? or we dont want to manage our database and want to write everything there in our c# code (code/data first)

Why EF was introduced, if only code management was the problem then, Why and how we are compromising with the performance and speed of query execution, even ORMs has limits.

Please answer my question and let me know if any edit is required.

My only concern is Speed and performance of my website.

Thanks in advance.

Answer 1

I'll try to answer all your questions based on my experience:

1. Why ORM? ORMs are very good in Model-First approach. When you have your model (your classes, objects, entities, ...) and decided to save it to some storage (DB for example). And here you take suitable ORM and tell it "ok, this class goes to this table" and so on. And this way reduce your DEVELOPMENT time. Of course, you have some overhead on mapping. But, in my experience I had no performance problems with mapping. I had performance problems in all other parts (DB queries, UI render, WCF, ...) but not ORM mapping. So, ORM reduce your development time, insignificantly degrading performance.

2. ORMs reduce duplicating, reduce complexity and highly increase development time!

3. Writing everything in C#? Partly - yes. ORM offers strong mapping, so it's nearly impossible to make stupid mistakes like comparing int and string, setting null to not-nullable properties and so on. So, ORM with LINQ-provider offers protection of your code.

4. Your concerns about performance are exaggerated. Of course, EF (or other ORM) is slower than hand-written SQL code. I believe that in 99% of cases EF will satisfy you and it's much easier to maintain this code, it's self-protected and self-explained.

So, don't look at numbers. They don't have anything common with real life. If you need some additional, I'll try explain.

Answer 2

I would like to add that the Comparison Chart of Dapper is a bit misleading, Entity Framework have one contra - a long startup time (631ms in the Chart). But that's just the first query against the database where models and so one are build in memory.

One thing a ORM can do for you is writing perfectly highly optimized SQL Queries, while at your end you dont have to worry about SQL Syntax and how to map your POCO's to your database tables. Use the ORM Objects like any other IEnumeration.

PS: Would prefer this as comment but < 50 Rep :(