What percentage would you give each of them based on:
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.
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.
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.
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.
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.
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.