Entity Framework vs Stored Procedures

I am only starting with Entity Framework and I appreciate the direct mapping of code to the tables in my database. What I do not see just yet is the practicality of having to use EF over stored procedures and I would appreciate anyone's opinion about this. I am not being lazy and I am searching this myself at the moment. Thought I can post the question and hear from others as well.

My case is EF being an ORM is most suited to mapping in the tables开发者_JS百科 in my database. But in a live web server many requests can happen at one time that may be taxing the database in having to compile the text queries prior to executing them compared to just simply executing stored procedure which are pre-compiled already. EF can also map to SPs but I feel that this is somewhat diminishing the value of ORM.

I would really appreciate an eye-opener in this case.

You might find Jeff's commentary on the subject helpful: http://www.codinghorror.com/blog/2005/05/stored-procedures-vs-ad-hoc-sql.html.

His point is basically that stored procedure's can be seen as a kind of premature optimization, and you really should make sure this is the performance bottleneck in your application before going that route. For instance, there are frameworks available to mock up 1000's of simultaneous web requests to see how your database will really perform under load in one situation versus the other.

Just because EF isn't using sprocs, it doesn't mean that the parameterised queries it runs won't get compiled and cached. SQL Server has got a lot more clever about that over the years.

One possible approach: - dynamic sql for single objects - SPs for parameterized lists and orders

The value of the ORM is usually its simplicity in creating the object model. One approach is described here: http://www.codeproject.com/Articles/362034/Populating-a-business-logical-layer-from-stored-pr