locked
Custom back store and SavingChanges event RRS feed

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 Sun

    MSDN 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, 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/

    http://blogs.msdn.com/b/adonet/archive/2009/06/10/poco-in-the-entity-framework-part-3-change-tracking-with-poco.aspx

     

    Good day!

     

     

    Best Regards,
    Lingzhi Sun

    MSDN 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.
    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 Sun

    MSDN 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, 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 Sun

    MSDN 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 Sun

    MSDN 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