Is there a benefit to override the default Insert/Update/Delete queries for EF

As the question asks really.

The EF modeller tool al开发者_如何学编程lows us to map the Insert/Update/Delete functions to a sproc, is there any benefit to overriding them?

If it requires some custom validation, then obviously yes, but if I'm happy with how it is now, is it worth creating sproc's for them all?

I can't remember how to view the SQL it's executing for them to find out the exact query, but I should imagine it'd be pretty similar to a standard Insert/Update/Delete query.

I can think of a few cases where it could be useful:

• You're working with a legacy database which doesn't quite map to your EF model precisely.
• You need extra queries to be executed on insert/update/delete, but you don't have rights to triggers on your database.
• Soft deletes in your database which you want to abstract away from. So a regular delete will actually perform a soft delete.

Not quite sure how viable these options are, as I personally am more of a NHibernate guy. These are theoretical options.

As for viewing the executed queries, there's a few possibilities to do that. You could attach a profiler to your SQL Server instance and look at the raw queries that are executed. There's also Entity Framework Profiler (By Ayende/Oren Eini) which isn't free, but it does make reading and debugging the queries a lot easier.

Yes. There is a benefit to overriding them.

Not everybody actually updates or deletes a row of data when an update or delete happens.

In some cases, deleting a record really simply means setting an EffictiveUntil date to an existing record and keeping the record in the database for historical purposes.

The same can go for an Update. Instead of updating an existing row, the current row gets the EffectiveUntil date set and a brand new row gets inserted with the new data with a null EffectiveUntil date (or similar mechanism).

By providing Insert/Update/Delete logic to Entity Framework, you are allowed to specify exactly what those operations mean in terms of your database rather than what they mean in the scope of an RDBMS.

As for the second question (that I apparently originally missed), if you're happy with what is currently being generated, then no it's not worth creating them. You'd just add the extra headache of having to remember to update your Stored Procedures whenever you change the table structure.