Answered by:
Custom back store and SavingChanges event

Question
-
Hi all,
I am looking into writing my own override of SaveCahnges, see this post for reasons:
My first step would be to invoke SavingChanges event which I cannot becuse it is an event and the function OnSavingChanges() which invokes it for the original implementation is private. Is there a reasonable way of doing it?
Is it even reasonable to try overriding SaveChanges() withour calling base.SaveChanges() at any point?
Best,
Asher
Thursday, June 24, 2010 12:15 PM
Answers
-
Hi Asher,
For questions a & b & c: the SavingChanges event is fired at the beginning of the base.SaveChanges(), and it is just an event. If we realize our own ObjectContext class, we can declare our own event which is fired when our override SaveChanges method is called.
For question d: if your concern is the transaction, we can keep the same transaction on our own update logic and the base.SaveChanges method. From the MSDN document Managing Connections and Transactions (Entity Framework), “When you call SaveChanges, if a current transaction exists, the Entity Framework uses this transaction for operations against the data source. Otherwise, it creates a new transaction for the operation. You can define transactions by using EntityTransaction, Transaction, or TransactionScope.”
Of course, we need to be very careful if we combine our own update logic and base.SaveChanges method. How to control it is really a “it depends” question.
Good day!
Best Regards,
Lingzhi SunMSDN Subscriber Support in Forum
If you have any feedback on our support, please contact msdnmg@microsoft.com
Please remember to mark the replies as answers if they help and unmark them if they provide no help.
Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.- Proposed as answer by Michael Sun [MSFT]Microsoft employee Thursday, July 1, 2010 1:25 AM
- Marked as answer by Michael Sun [MSFT]Microsoft employee Friday, July 9, 2010 7:27 AM
Tuesday, June 29, 2010 9:43 AM
All replies
-
Hi Asher,
If we override the SaveChanges, we can add our own business logic on the new implementation of SaveChanges method, which means we don’t need to fire SavingChanges event, right? Please feel free to correct me if I misunderstand it.
For the second question, I think if we have some custom CUD methods to execute, we don’t need to call EF4’s base SaveChanges, but please remember to call AcceptAllChanges after the CUD methods is finished running. However, in most scenarios we still need the EF4’s SaveChanges to update the database since it wraps the transactions, connections and etc, which is very powerful. In other situations, we may use some mixed pattern: using some custom CUD methods and then still calling the base SaveChanges. Note that we need to sync up the entity status to avoid any duplicate update operations.
Additional references:
http://blog.cincura.net/230662-savechanges-is-virtual-in-ef4/
Good day!
Best Regards,
Lingzhi SunMSDN Subscriber Support in Forum
If you have any feedback on our support, please contact msdnmg@microsoft.com
Please remember to mark the replies as answers if they help and unmark them if they provide no help.
Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.- Proposed as answer by Jonathan Aneja -- MSFT Friday, June 25, 2010 7:04 PM
Friday, June 25, 2010 2:33 AM -
Lingzhi hi,
a. The EF context I am creating would be used by thid parties so they might (rightfully) expect the event called 'SavingChanges' to be to be invoked before changes are commited.
b. Even for internal use, it is rather unreasonable to have an event not fiering when it is suppsed to.
c. Calling 'SavingChanges' halfway through the process of saving changes is also not realy good design as the user of the event may access the context and expect all changes to be there, uncommitted.
d. For that matter, calling base.SaveCahnges() halfway through the process of saving changes is also not realy good design if you already saved some of the changes for the same reason.
Doing half the job yourself and delegating the rest to ase.SaveCahnges() is not really effective. You can't use a unified transaction, you cannot have use the connection, you cannot save the objects in the right order to satisfy foregin key constaints etc. I have not intention of using base.SaveCahnges() at all.
My question is, would your design really supports replacing commit logic or is it just a port enabling some pre and post commit actions?
Asher
Sunday, June 27, 2010 11:50 AM -
Hi Asher,
For questions a & b & c: the SavingChanges event is fired at the beginning of the base.SaveChanges(), and it is just an event. If we realize our own ObjectContext class, we can declare our own event which is fired when our override SaveChanges method is called.
For question d: if your concern is the transaction, we can keep the same transaction on our own update logic and the base.SaveChanges method. From the MSDN document Managing Connections and Transactions (Entity Framework), “When you call SaveChanges, if a current transaction exists, the Entity Framework uses this transaction for operations against the data source. Otherwise, it creates a new transaction for the operation. You can define transactions by using EntityTransaction, Transaction, or TransactionScope.”
Of course, we need to be very careful if we combine our own update logic and base.SaveChanges method. How to control it is really a “it depends” question.
Good day!
Best Regards,
Lingzhi SunMSDN Subscriber Support in Forum
If you have any feedback on our support, please contact msdnmg@microsoft.com
Please remember to mark the replies as answers if they help and unmark them if they provide no help.
Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.- Proposed as answer by Michael Sun [MSFT]Microsoft employee Thursday, July 1, 2010 1:25 AM
- Marked as answer by Michael Sun [MSFT]Microsoft employee Friday, July 9, 2010 7:27 AM
Tuesday, June 29, 2010 9:43 AM -
Hi Asher,
I am writing to check the status of the issue on your side. Would you mind letting us know how is the problem now?
If you need further assistance, please feel free to let me know. I will be more than happy to be of assistance.
Have a nice day!
Best Regards,
Lingzhi SunMSDN Subscriber Support in Forum
If you have any feedback on our support, please contact msdnmg@microsoft.com
Please remember to mark the replies as answers if they help and unmark them if they provide no help.
Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.Tuesday, July 6, 2010 1:03 AM -
Lingzhi Hi,
Thank you for your efforts. However, I am afraid I am misunderstood. Creating another event is not an answer to the fact that the original event would not be called when expected.
If the SaveChanges() mechanism is to be replaceable, the method invoking the event should be protected.
Asher
Sunday, July 11, 2010 1:50 PM -
Hi Asher,
I agree with you. I would recommend you open a suggestion at the Microsoft Connect. Making the event protected can be considered by the product group in the next release of EF.
Good day!
Best Regards,
Lingzhi SunMSDN Subscriber Support in Forum
If you have any feedback on our support, please contact msdnmg@microsoft.com
Please remember to mark the replies as answers if they help and unmark them if they provide no help.
Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.Monday, July 12, 2010 6:29 AM -
Thanks,
I posted request 651743
Asher
Wednesday, March 16, 2011 11:57 AM