Strategy for using stored procedure with extra params in Entity Framework 4

I have a situation where business requirements dictate that all data access is done via stored procs. I chose to use Entity Framework because I knew the Stored Procedure support was greatly improved in 4.0

However, I have a set of procedures which include some extra params (UserName, ReasonCode, etc...) that will be used for additional logic in the proc. This is a pretty common scenario so I am astounded that EF makes it so incredibly difficult to achieve this.

As I see it my only options for getting around this are as follows:

1. Create a view in the database that queries the underlying table, and includes the extra column names with null values.
2. Handle the SaveChanges event, or override the SaveChanges method on the context and manually handle the function calls there.

Option 1 is out of the question on my current project, although it would be the easiest.

Option 2 is an incredible amount of work. The whole point of EF is to save me from having to write mind-numbingly tedious data access code that will be error prone. Let's look at the potential amount of work involved here:

1. Create a function import for each entity needing this info, and for each modification action necessary (Insert, Update, Delete)
2. Create some common type that holds all that information, and apply it to each entity via partial classes.
3. Write a mapping function for each method for every entity (3*N) Note that this also involves getting original values for Update and Delete
4. O开发者_如何学Pythonverride the SaveChanges method to inspect each Entity to see if it is the correct IFoo interface, check the state of the entity, and then call the appropriate method for that entity type.

Am I missing something??? Why would such a common scenario be so difficult to perform.

I know someone is probably thinking I could write a T4 template to generate all this code for me, but that just brings me back to the point that it is tedious boilerplate code that adds no real value. There simply has to be an easier way to just say:

"Yo EF! I am calling a proc! I know what i'm doing and I want to add these extra values in capiche?"

Extra info for the curious:

• I'm using the Self-Tracking entities template with WCF
• The additional params do not exist anywhere that can be linked to by the Entity
• The additional params are always the same
• The stored procedures are as is, they cannot be modified from their current contract

Any help or insight into this matter would be most welcome!

Cheers,

Josh

The whole point of EF is to save me from having to write mind-numbingly tedious data access code that will be error prone.

Right, and the way it does this is by writing the boilerplate code for you, using a T4 transform.

I know someone is probably thinking I could write a T4 template to generate all this code for me, but that just brings me back to the point that it is tedious boilerplate code that adds no real value.

... which is why leveraging T4 seems like an obvious way to solve this problem. The code you're describing is no more tedious than the code that the Entity Framework is already generating for you. You can actually change your entity contexts so that the .edmx.cs files are generated by your own custom T4 template in the first place, rather than by Visual Studio's built-in transform.

I've not had to use stored procedures in Entity Framework yet, so there may be a better way to do what you're describing, but I wouldn't be too quick to discount the T4 approach if it can solve your problems adequately.

There is a thread in msdn forums on this topic:
http://social.msdn.microsoft.com/Forums/en-US/adodotnetentityframework/thread/182c99d0-5fde-4292-b356-4f9a4d86e032/
I'm experiencing the same problem and I guess I'll go just with the CUD procedures as standard function imports instead of using SaveChanges().