Home/ Questions/Q 5979301
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-22T21:38:24+00:00

My company uses stored procs for all SELECT operations so it’s making it rather

  • 0

My company uses stored procs for all SELECT operations so it’s making it rather difficult for me to create sensible navigation properties. I’m not too concerned at this point whether they’re lazy loaded or not.

So for example I created an entity for Customer then created a FunctionImport to map GetAllCustomersSP to return a collection of Customer entities. But I want a navigation property “Orders” on each Customer entity.

But if I use the Customer entity partial class to just add this property, the problem is that I don’t have access to the original Context, so I can’t call the GetCustomerOrdersSP either explicitly or deferred.

The only option I can see is to modify my repository to add these properties in explicitly, which seems lame because it puts the entity logic into the repository.

Is there something I’m missing here? I can see in the entity model designer that I can specify custom insert, update, delete SPs but I don’t see any way to use select SPs to actually retrieve the data.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I agree with Tim here…any solution you come up with isn’t going to fully leverage the ORM and will be a potential nightmare to maintain. I would suggest creating a model, in code, that is framed in the manner in which you want to develop.

    In the Data Access layer of your app, you can map your data objects that use SPs to hydrate your model objects (have a look at AutoMapper). Your app will only know about your model objects.

    Doing this will give you a consistency in how you interact with the objects, and you can begin to apply pressure to the powers that be to allow more fine grained access to the tables, at which point, you can adjust your Data Access Layer to support EF and remove SPs. At this point you would be able to consider migrating the objects you created to POCO objects that are persisted via EF.

    We had a similar issue in that granting raw DB access was “forbidden”. We overcame this problem by using a model in which we only grant access to tables as they are used, not the entire database, and by ensuring the DBA that EF uses parameterized SQL, eliminating the concern of SQL Injection.

    • 0