views:

24

answers:

1

So I have a customer requirement to only use stored procedures for all database operations. I created CRUD stored procedures for each of my tables, and then created my Entity models.

So I see easily how to map my Insert, Update and Delete stored procedures to my entity (Customer for example), but there seems to be no way to map my Select? This is just a plain old select, it should just return a list of my Customer entities- so it maps directly to my Entity type, it is not custom. It seems the only way to do this is to import a function and map that instead.

So why no ability to map Select directly? There would be huge advantages for me to do this!

Maybe my stored procedure isn't suitable somehow?

Anyone have any ideas?

+1  A: 

You would use the feature in EF that allows you to add stored procedures to the diagram and these become methods you can invoke directly. If you then open up the Model Browser, then track down the SELECT procedure(s) you added, you can double-click each one and bind the return type to the entity model. The calling convention would then be

MyEntity entity = myDB.MyStoredProcedure().FirstOrDefault();

HTH, Jon

stimpy77
This is a workaround, which I am using. But it doesn't really solve the problem- for example with a DomainService class, it wants to use the Customer property to get properties- I have to manually change my service to use my imported function- which is bad if I need to regen my service. Insert Update and Delete can be mapped so that at the entity level they are used. But you cannot do this for select.
Nicros
It's not really that much of a "workaround", it seems logically legit. For selects, as I mentioned ("bind the return type to the entity model") stored procedures can be mapped directly to an entity type, rather than a type specific to the stored procedure function. So, in my example, MyStoredProcedure() returns an instance of MyEntity, not of some thing else. By default it's something else, you have to map the output to MyEntity manually from the imported interface level, this being the opposite end of assigning the sproc to the entity. Same difference really, just different place.
stimpy77
Sorry if I wasn't helpful enough, but to answer your original question, there's not much that can be done if the lib still has this limitation. Right now I'm still upset that INSERT via SPROC won't bind the IDENTITY column to an output parameter. For being supposedly "enterprise-class", EF4 is still pretty pathetic no thanks to this and the workarounds one must produce.
stimpy77