What's the difference between Entity Framework, LINQ to SQL, and ADO.NET with stored procedures?

ado.net entity-framework linq-to-entities linq-to-sql sql


What percentage would you give each of them based on:

  1. Performance
  2. Developmental pace
  3. Clean, logical, and maintainable code
  4. Flexibility
  5. Overall

I've always loved ADO.NET and stored procedures since I love my SQL, but I just tried out Linq to SQL and was amazed at how fast I could write out my DataAccess layer. As a result, I've chosen to invest some time fully studying either Linq to SQL or EF—or neither?

I simply want to make sure that none of these technologies have a significant defect that would make my research effort pointless. For instance, the performance is poor; it's great for simple programs but has its limits.

Update: Instead of focusing on ORM VS SPs, can you concentrate on EF VS L2S VS SPs. EF VS L2S is what interests me the most. However, given that I have a lot of experience with plain SQL, I would want to see them compared to stored procedures as well.

4/23/2010 1:48:40 PM

Accepted Answer

First off, if you're beginning a new project, use Entity Framework ("EF") instead of Linq to SQL since it now creates far better SQL (more like Linq to SQL does) and is simpler to manage ("L2S"). Since.NET 4.0 has been released, I believe Linq to SQL to be an old technology. MS has been quite transparent about not pursuing additional L2S development.

Performance: 1

Answering this is challenging. You will discover that the performance of all three technologies is about comparable for the majority of single-entity operations (CRUD). To utilize EF and Linq to SQL to their greatest potential, you do need to be familiar with how they operate. You may wish to have EF/L2S "compile" your entity query for high-volume actions like polling queries so that the framework doesn't have to keep regenerating the SQL, else scalability problems may arise. (view changes)

Because you don't have to marshal the data over the wire to the ORM to execute updates, raw SQL or a stored procedure will always perform better than an ORM solution for bulk updates if you're changing enormous volumes of data.

2) Developmental Speed

In most cases, EF will outperform raw SQL/stored procs in terms of development speed. In order to avoid synchronization problems between your object code and your database code, the EF designer may (upon request) update your model from your database as it changes. The only situations in which I wouldn't think about utilizing an ORM are when you're building a reporting or dashboard application without performing any updating, or when you're building an application just to do database maintenance tasks on raw data.

Three) Clean, maintainable code

By far, EF outperforms SQL/sprocs. Joins are quite rare in your code since your connections are modeled. For the majority of queries, the reader can nearly always infer the connections between the entities. Nothing is worse than having to go through many SQL/middle tiers or tiers of debugging to figure out what is really happening to your data. With the help of EF, your data model is powerfully integrated into your code.

4) Adaptability

Raw SQL and stored procedures are more "flexible". For the occasional unique scenario, you can use sprocs and SQL to make quicker queries, and you can use native DB capability more easily than you can with an ORM.

5) General

Avoid falling prey to the false choice between employing stored procedures or an ORM. Both may be used together in one application, and you should. Large-scale activities should be performed in stored procedures or SQL (which the EF can really call), but the majority of your middle-tier requirements should be met by EF. You could decide to write your reports using SQL. The lesson of the narrative is, I suppose, still the same as it always has been. Use the proper equipment for the task. But the short of it is that EF is excellent right now (as of .NET 4.0). Create some incredible, high-performance applications with easy if you take the time to study and comprehend it thoroughly.

EF 5 makes this step a little bit easier using automatic LINQ queries, but for very large volume work, you'll need to test and evaluate what works best for you in the real world.

2/21/2020 9:50:45 PM

Popular Answer

stored methods:


  • superior adaptability
  • complete command over SQL
  • maximum performance potential


  • need understanding of SQL
  • Stored methods are not under source control.
  • Significant amounts of "repeating yourself" with the same table and field names specified. high likelihood of breaking the application after renaming a database object and forgetting to update certain references to it.
  • slow progress



  • development quickly
  • Code for data access is currently under source control.
  • You are shielded from DB updates. If that occurs, you simply need to make one modification to your model and mappings.


  • Performance could decline
  • No or little control over the SQL that the ORM generates (could be inefficient or worse buggy). It could be necessary to step in and substitute custom stored routines. Your code will become disorganized as a result (some LINQ, some SQL, and/or some code in the database that is not under source control).
  • Because any abstraction might result in "high-level" developers who are unaware of how it functions in the background

The typical trade-off is between having a lot of freedom and wasting a lot of time and having fewer options but getting things done fast.

This question does not have a universal response. It has to do with holy warfare. Depends also on the job at hand and your requirements. Decide what suits you the most.

Related Questions


Licensed under: CC-BY-SA with attribution
Not affiliated with Stack Overflow
Licensed under: CC-BY-SA with attribution
Not affiliated with Stack Overflow