I'am using EF6 code first model, Not getting any proper solution to map an existing Stored Procedure.

Topics: General
Dec 6, 2013 at 5:36 AM
I'am using EF6 code first model, Not getting any proper solution to map an existing Stored Procedure.
Can anyone give me the best solution for this, i need call the Repository from my Service.
Am using WebApi
Dec 8, 2013 at 3:10 PM
I second that. I have a pretty big Model FIrst database with all the limitations of ridiculous design decisions and a designer being an example of how to totally kill usability (in the update method). As a result I am considering moving to CodeFirst.

Sadly, there seems to be zero support for stored procedures, outside mapping them for CRUD operations. Sadly, my stored procedures are mostly not "I do not trust an ORM" but focus on database level business logic.

Example are a 3 page Select statement using things like partition over to do analysis over multiple dozen million rows, as well as a stored procedure that does bulk deletes - by swapping out partitions. Both sides impossible to do with Entity Framework. Not that I blame EF here - that stuff is heavy duty database stuff and outside the scope of an ORM.

THat sadly, though, points to EF design living in an ivory tower and having ignored the requirement for calling stored procedures from code First. While something as old and primitive as BlToolkit has had nice low level functions for that for ages (example at http://bltoolkit.net/Doc.DASprocName.ashx).

Do I really have to dig deep into writing low level code as per



Is there anything more easy planned? 6.1? 7.0? Version 99 in the year 2130?

Right now those of us who are not living in a land of totally trivial database interaction are stuck with a bad designer or an anemic code first model.

It would really not be that bad if the Model First approach would not totally be ridiculous in the maintenance side.

My main complaints are:
  • Updating a stored procedure of 100 when parameters change or - god beware - the returned data has a different form - you have to manually delete parts of the XML in multiple places to then be able to sync the new definitions in. Pretty much all updates only work by "delete the elements, then sync back in" which makes maintaining diagrams a pain.
  • It is seriously not nice to have schema not part of the model names (so a table "Trade" in 2 schemata reallly does not result in usable nice names for the classes), and at the same time you can not put them into namespaces - not in the UI and not in Entity Framework where someone decided not following .NET standards is nice and thus assumes class names are unique.... NICE....
The result is pain. And model first now is the pain of having every stored procedure manually mapped? OUCH.