views:

46

answers:

2

Hi everybody,

Entity Framework allows to map the result of a stored procedure to an Entity easily. What I need is to map an Entity to input parameters, so that instead of

context.SaveUser( user.FirstName, user.LastName, ... );

I can simply call it like this:

context.SaveUser( user );

What I really want is to isolate possible schema changes as much as I can. I'm only using EF to generate entities and function imports; the entire interaction with DB is performed through function calls. So whenever User table changes, I want to regenerate User entity in visual designer and change business logic code as appropriate; I do NOT want to change the data access layer. Currently, I'm not seeing any way around those property set dependent calls from data access layer to EF (like the one I posted above), which is a shame, since those could easily be regenerated along with entity classes.

Is there any other strategy which would allow me to achieve the same? The reason I'm using those stored procedures is actually because I want to have full control over SQL (maybe I'm just being paranoid, but it's kind of scary to end up with piles of LINQ code with little or no way to control actual SQL).

Is such thing possible?

Thank you

A: 

I don't think it is possible without some additional boilerplate code.

Maybe you should re-think your current access strategy and not use Stored Procedures. Then you will be able to do it like want.

Robert Vuković
A: 

This is possible but in different way than you are trying to achieve it. Each entity allows mapping of Insert, Update and Delete actions to stored procedures. So in your case, I assume you need to create mapping for Insert and Update action to SaveUser stored procedure. When mapping is done stored procedure is called internally each time the entity is added or updated in entity set and SaveChanges is requested. So you will work with entity set in the same way as without stored procedures. Check these articles on MSDN: How to and Walkthrough.

Edit:

Try to use mentioned approach and save changes this way:

var user = new User();
FillUser(user); // fill modified data to user entity

using (var context = new MyContext())
{
  context.Users.Attach(user);
  context.ObjectStateManager.ChangeObjectState(user, EntityState.Modified);
  context.SaveChanges(); // This should call your Update stored procedure
}
Ladislav Mrnka
That's what I originally intended to do, but the thing is, in order to Insert, Update or Delete an entity you need to get it from the context first. There is no Select action to be mapped to a stored procedure, and my user doesn't have a Select permission on the database. Kind of messes up the whole idea...
tokaplan
Why do you think that you first have to get entity from the context?
Ladislav Mrnka
Well, maybe not every time, but most of the time - unless I'm creating a new entity, of course. The typical scenario is to get an Entity from database, do something with it, and maybe save it back. EF tries to generate an SQL query every time I try to get an entity from database, and it looks like there's no way to make it call a stored procedure instead. I don't need EF to do all the JOINs for me, I'll do that inside an SP if I have to.
tokaplan
You don't need to query DB before working with entity in application. How do you think the web application using EF works? Yes in some cases it is easier to query the DB, get entity and make updates in attached entity but in same way you can create new instance of entity in your code (without querying) fill new values to entity, attach the entity to context, set entity state to modified and save changes.
Ladislav Mrnka
I added some code snippet showing how to force EF to update entity which wasn't previously loaded by query.
Ladislav Mrnka
So what you're saying is that I can store the value of primary key property for the entity (say, in ASP.NET Session), and then simply fill a newly created entity's id with it and Attach() the object. Am I understanding correctly?
tokaplan