Question

I am just starting out with the Entity Framework 4.0 and ASP.NET MVC 2 and have a few questions regarding the use of stored procedures and paging.

You can map the Insert, Update, and Delete actions to stored procedures and I have already done this. However for my paging to work I need to map the Select action.

Now is the only / best way I can do this by going to my model browser, right clicking on the stored procedure and “Add Function Import” and adding it.

This results in the following code….

var contactFormSubmissions = _entities.ContactFormSubmission_GetContactFormSubmissions(1, 10);

My issue with this is that it adds it to the global entity container at root level rather than the ContactFormSubmission entity like the Insert / Update and Delete actions.

I would rather something like this but through through a stored procedure…

_entities.ContactFormSubmissions.Select<ContactFormSubmission>(string.Empty, pageParam, pageSizeParam);

This way the select is called in the same way as the other actions and I dont end up with lots of functions in the root of the Entity Container which could get unmanagable.

This is a lesser issue as at least its all working currently.

My next question is how to best implement paging using this function.

All of the examples I have seen on how to accomplish paging using MVC and the Entity Framework have used LINQ and IQueryable. Is there a way of using IQueryable with lazy loading and the LINQ functions Skip / Take with a table based function /sproc?

http://blog.wekeroad.com/2007/12/10/aspnet-mvc-pagedlistt/

PS – any examples of paging in MVC with the Entity Framework using SP’s would be great!

Answer 1

LINQ out of the box will not wrap a stored procedure. Entity Framework functions are the only way to call stored procedures via EF and return an entity. It’s understandable, as EF has know what of knowing what parameter to map your paging variables too.

You would/should never do this, but I feel compelled (since nothing is impossible) to say you could write a custom implementation of LINQ for your procedures, but that would be a mountain of work to cleanly wrap a couple of procedures.

Some suggestions:

• You can just use linq and skip the stored procedure
• If you stay with EF wrapping a stored procedure via a function, you can alleviate the many function problem by breaking up your model into several contexts
• You can use the connection property of the EF context to call the stored procedure directly, and have a read-only(non-EF attached) viewmodel class to use for display purposes. The id (or other primary key) field would still be the right value to get you to a detail screen or json callback to get an editable version of the real EF object

None of these are perfect, but lots of ways to deal with this.