MVC 3 using Stored Procedure vs Entity Framework 4

We are starting a MVC 3 Project with Razor and i am confused which approach to take when it comes to accessing/updating data. I know we have the following options.

* Plain old ADO.NET
* LINQ to SQL
* NHibernate
* Entity Framework

But i am more inclined towards using Plain Old ADO.Net (Since i think this is the fastest) I would still use the Model classes, but once i get the data from the class, i would like to go ahead and call a stored procedure u开发者_运维问答sing Plain Ado.Net, rather than using EF Update methods.

I would like to get your opinions if there are any disadvantages to this approach compared to using EF.

(This is going to be a public website with lot of traffic !)

I was asked this by a candidate in a an interview this week. We only use stored procedures and the ADO.NET methods. We chose this because, we have found that to make great performing applications with ORM you need to be an expert in using it. Since I do not have any experts in ORM and I do not plan on creating/hiring any, it makes sense to stick with the stack that we know.

I say that you need to be an expert because of the way that ORMs such as Hibernate (or NHibernate) create the relationships and consequently the SQL (mostly joins, etc). I think that ORM is great for small tools or RAD environments where things MUST get done fast and also may not live forever. I think for the larger enterprise applications where maintenance and performance is more critical, then ADO is safer. This does not mean it is not impossible, but more care must be taken to ensure it.

I know that this is a very hot topic and that ORM is a lot simpler than ADO, but honestly ADO is not that hard. I am eager to hear what the rest of the community has to say about this!

NHibernate is great if you want to abstract your code away from relying on a specific database, but it would seem you've discounted this - don't have this as a requirement.

In your case I'd recommend going down the EF route, and then look to 'plain ado.net' if you find you're experiencing any performance bottlenecks.

To clarify, in response to this question;

"so you think going with EF route is much efficient than just calling the stored proc with Plain Old Ado.net when dealing with large amount of data"

EF creates efficient code, but you may encounter situations where you need to tune the code and/or the database if you see performance issues. The advantage of using EF, or some other ORM, is that you'll be a more productive developer, it will save you time and allow you to concentrate on the business rules, etc. rather than crafting your data access by hand using ado.net

I made a public website with around 60Gb of bandwidth waste per day (site only run from December 1st to December 24) and I did choose Entity Framework with LINQ.

I had no complain about EF... only the server that couldn't handle so many users and I had to put all images into Amazon S3 (using Amazon .NET SDK) to remove the extremely amount of bandwith per day.

EF caches the calls so when retrieving the same object EF is smart enough not to call the database again and return the cached object, all was made extremely well and I have to say that I was reticent against EF when i started the project, but at the end, it was a WIN!