0

There is an enterprise project, which all the business implemented in databases and in the stored procedures, and web API is just like a light wrapper which get the request and deliver it to proper SQL server sp and return the returned response from SQL server to client.

(except some discussions, and pros and cons of this kind of implementation which had discussed before here and here ), what is the best way of calling sp for a project with hundreds of request per second : with entity framework or with ado.net or there is not a huge difference between them?

Community
  • 1
reza damavand
  • 133
  • 1
  • 3
  • 3
    Seems like with the environment you have in place, this is something you could test yourself very easily. – JeffO Mar 15 '17 at 12:52
  • but some one may know it, and test it before! I don't want to reinvent the wheel again!!! – reza damavand Mar 15 '17 at 12:54
  • 4
    @rezadamavand you wouldn't be reinventing anything. You would be finding what works for your *specific* situation. There's no better data than first-hand data. – MetaFight Mar 15 '17 at 12:57
  • 3
    If all the interaction is required to be via stored procedures, EF brings very little to the table. – TZHX Mar 15 '17 at 16:44
  • 1
    [Calling Stored Procedures from Entity Framework](https://visualstudiomagazine.com/articles/2014/04/01/calling-stored-procedures-from-entity-framework.aspx) – Robert Harvey Mar 15 '17 at 16:53
  • If i'm working with an application where I return very few fields from the db and tell you there's no difference, that doesn't really help you if you have to return 75 columns of data. What may be common in your environment, may be a non-existent edge-case in mine. That's just one example. Maybe large text blobs make a difference? – JeffO Mar 22 '17 at 14:58

2 Answers2

1

You can call sprocs via EF no problem, and I expect the speed is going to be comparable.

The question is why would you? The benefit of EF is the automatic mapping of tables to classes and vice versa.

When you us sprocs you bypass all that and indeed for the kind of microsevice api you are talking about you don't tend to have the long persistence and manipulation of objects anyway.

EF is/was sold as the M of MVC, making database interaction without having to learn SQL and muck around with datasets and adaptors.

But for enterprise level stuff where you want to tweak the SQL execution plans, separate out responsibility to a DBA team etc its not always a good fit.

Ewan
  • 70,664
  • 5
  • 76
  • 161
0

EF is really just a shell around ADO.Net. There may be technical differences that surpass the detail intended in this answer; my approximation is that EF is essentially an additional automation layer on top of ADO.

Running the stored procedure is going to be handled by the database, so the performance argument is irrespective of the stored proc's inherent performance (it'll be the same either way).

The only thing that can make a difference in performance is how you process the result of that stored procedure. Use EF's "black box" entity mapping, or roll your own.

This means that the essence of your question boils down to "do you think that you can write a better mapper than the EF team did?"

I'm going to go ahead and say no. I'm not saying EF is perfect, and I don't know you enough to gauge your skill level; but EF's performance is above what I expect the average developer to create, and thus EF is statistically more likely to outperform a random developer's code.

Flater
  • 44,596
  • 8
  • 88
  • 122