Stored Procedure Mapping RRS feed

  • Question


    Is it true that if I have a stored procedure named sp_A that has result columns named sprA, sprB and sprC, then the only way I can return an entity set from that stored procedure is to define an entity with named properties sprA, sprB and sprC ?


    I want to define an entity with reasonable property names that correspond to (unreasonable) stored procedure result names, much in the same manner that one maps column names in a table to an entity's properties. Is this not possible?


    Thursday, April 3, 2008 5:17 PM


All replies

  • You can alias a stored procedure column name to a different property name in Map Entities to Function version of the Mapping Details pane, which has separate columns for stored procedure parameters and entity properties. See the

    screen capture near the end of Migrating to SQL Server Stored Procedures with the EDM Designer December CTP 2.




    Thursday, April 3, 2008 6:25 PM
  • With the current runtime, yes, this is the restriction. The good news is that Colin Meek has released a set of extensions that allow you to do what you want with a simple bit of code:



    Thursday, April 3, 2008 7:46 PM
  • Thanks for the response; however, that's just ridiculous. One of the main purposes of the entity framework is to facilitate separation of concerns between an application's logical model and the physical data model - or so it is advertised. To realize this is only possible using ad-hoc techniques and is not built into the framework is very discouraging. Do you realize how many enterprises only allow access to data via stored procedures and that, often, the author of a given stored procedure has no real sense of the contexts in which it may be used?


    This is just one more piece of evidence that the EF doesn't support persistence ignorance properly. Over a year ago, I posted a message to this forum denoting very specific aspects of EF that violoated PI and had some very specific questions to which I was promised a response. That response never came. You can view the thread here:




    I would very much like to use the EF, but now that it's probably in its final form, I am realizing that it just won't work in situations where you want TRUE separation between a persistence model and a domain model. The sad thing is that with some slightly different design choices, the EF would have been wonderful. But as it stands, I can't justify using it because it simply will not allow me to persist PLAIN OLD CLR OBJECTS.


    Maybe I'm mising something. If there's a way to take a class that has NO dependence on the EF and use the EF to persist/reconstitute it using only metadata specified in the xml files, please let me know.




    Friday, April 4, 2008 12:24 PM