This is not possible in EF 1.0
The reason is that EF will treat stored procedure values as values, not navigation properties.
For example, an Employee object has several Order objects. In order, you have a property called EmployeeID. When the database fills your query using include statements, it creates 1 forecast query in SQL to populate all the order data that a particular Employee could have.
So if I said
var employee = context.Employees.Include ("Orders"). Where (e => e.ID == 1) .First ();
var orders = employee.Orders;
SQL for the first query will create a projection query that will contain orders, where EmployeeID = 1.
Now that your stored procedure starts, any code behind the scenes can do this (in other words, it can return any data set). Therefore, when SQL starts the stored procedure, it simply runs the code in this stored procedure and does not know that the EmployeeID on Order is the FK for this property. Also, if your stored procedure returns an Employee object, you are looking at another script in which you won’t even have an OrderID to continue.
To get around this, you can customize your request in EF using Include statements, which can reflect any stored procedure. If you use the correct combination of .Select and .Include commands, you should be able to do the same.
jwendl
source share