Entity Framework or SqlDataReader [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 9 years ago.

Improve this question

I appreciate there are one or two similar questions on SO but we are a few years on and I know EF's speed and general performance has been enhanced so those may be out of date. I am writing a new webservice to replace an old one. Replicating the existing functionality it needs to do just a handful of database operations. These are:

1. Call existing stored procedures to get data (2)
2. Send SQL to the database to be executed (should be stored procedures I know) (5)
3. Update records (2)
4. Insert records (1)

So 10 operations in total. The database is HUGE but I am only dealing with 3 tables directly (stored procedures do some complex JOINs). When getting the data I build an array of objects (e.g. Employees) which then get returned by the web service.

From my experience with Entity Framework, and because I'm not doing anything clever with the data, I believe EF is not the right tool for my purpose and SqlDataReader is better (I imagine it is going to be lighter and faster).

Answer 1

Entity Framework focuses mostly on developer productivity - easy to use, easy to get things done.

EF does add some abstraction layers on top of "raw" ADO.NET. It's not designed for large-scale, bulk operations, and it will be slower than "raw" ADO.NET.

Using a SqlDataReader will be faster - but it's also a lot more (developer's) work, too.

Pick whichever is more important to you - getting things done quickly and easily (as a developer), or getting top speed by doing it "the hard way".

There's really no good "one single answer" to this "question" ... pick the right tool / the right approach for the job at hand and use it.