Good practices updating Business Objects Properties RRS feed

  • Question

  • Hi,

    I am having some trouble to find a good/correct practice to perform the update of some properties in my Business Objects. I am following MVP with WPF, where my Presenter (or a PM) is the wrapper of my BOs. My requirement:

    When the user changes some element in the UI (CheckBox or TextBox), i need to update the BO and then update the DB. If the operation fails I need to undo the change.


    Generally I would use two-way binding for the binding to update the properties through the setters of the properties. But this creates a couple of problems like:

    1- how/where to start the backup of the property (or BO)

    2- how/where to perform the rollback of the operation .

    I have a requirement though, my team leader does not want to use the IEditableObject interface because of the repeated/unknown behavior in some methods (StartEdit/CancelEdit/EndEdit could be called several times or to be called "whenever it feels like").

    Problem 1 - I am doing the backup of the property, inside the setter, before the actual setting of the value and I am keeping an extra field for each property that can be updated. Is this an okay procedure?

    Problem 2 - After the setting of a property I am handling the events (Checked/Unchecked of Lost Focus for the textboxes), and passing the process to the Presenter.There I am performing the update of the BO and at the DB.If the operation succeeds I just clean the backup. But if the process fails I need to backup the value. A couple of issues arise here:

    Problem 2.1 - is it ALWAYS guaranteed that the checked/lost focus events will be fired AFTER the property setting?I am asking this because binding seems to be asynchronous and I really need to perform the backup of the values before the vents fire

    Problem 2.2 - rolling back the value triggers a new backup and the firing of the Checked event

    Problem 2.3 - if I need to change the property programaticaly in my presenter through the property both the backup and event get fired and I do not want that because I am controling the change. Meaning, I just want to backup the value and trigger the event if the change comes from the UI. Would it be okay to just change the field directly and fire PropertyChanged, (overstepping the property setter)? I feel that this seems like bad practice because the property getters/setters are there for a reason...

    Having two-way binding is great but I feel like I am losing some control over the operation of my properties/BO and introducing unnecessary complexity.

    Do you guys have any suggestion/solution to my "problems"?

    I am considering using, for these complex properties, one-way binding and just control the whole backup, set (and possibly rollback) process of the properties in the presenter. Or maybe Two-way Binding with the Binding Mode to Explicit.


    Saturday, June 5, 2010 12:17 AM

All replies

  • Greetings

    Some links are given below

    Checked/Unchecked of Lost Focus for the textboxes

    Radio Button

    WPF RadioButtons and data binding


    Hope this helps

    Take Care


    Helping People To Solve Technical Problems
    Saturday, June 5, 2010 3:21 PM
  • Hi,

    First, thanks for your interest but my doubts are not related with presenting the data in a view.

    It is more related with the "correct way" to perform an update of a property to the DB (like a transaction: sucess ok, fail then rollback to the previous value).

    But thanks for the links about the radio buttons, they will come in handy.

    Saturday, June 5, 2010 6:06 PM
  • Personally, I would strongly recommend MVVM rather than MVP with WPF, but what the ____.

    Your issue is because you're trying to write each property change into the database rather than committing an entire record at a time.  That'll cause all sorts of complications in WPF.  Datagrids in particular just don't suit that way of working.   There is also the issue where your user starts changing stuff on a record and gets half way only to hit a validation error they don't want to or can't fix.  So you can end up with half completed rows of data and what do you do with it.

    Plus there's the overhead to the database server.  You'd do way better dealing with a record at a time.

    Another problem is where you put your validations.  You'd do better imo sticking them all in a separate method.  You can then control when you fire the thing so you can set a field to null without erroring.

    Monday, June 7, 2010 9:43 AM