Hello, I'm using CSLA 3.6 and I have some business rules in my business base object that claim to clean some fields when I change a property. These fields have business rules related with them so, when I'm restoring their value in my set propery, I'm using PropertyHasChanged(field_name).
If I have a lot of fields for restore to initial values, time to successfully run my entire Set property code is growing. How can I obtain this without time issues?
Thanks in advance, Marian
I read VB Expert 2005 BO and I found that It's not good to raise PropertyHasChanged for each derived property changed in my set principal property. I Invoked Validation.CheckRules for each property modified and PropertyHasChanged("propertyname") only for my principal property modified in set body.
I didn't find directly specified in book that data binding is invoked automatically for each property changed, even I call PropertyHasChanged only for principal property modified.
Set' answer time is dramatically improved.
I hope that is the right solution!
Hmm, well that depends though on what is actually causing the response to be slow.
The PropertyHasChanged will also send OnPropertyChanged events to make the UI is in sync. This may invole a lot of refreshing in the UI (and lists).
So you may need to aggregate the notifications from BusinessRules.CheckRules("propertyName").
This is the actual code from PropertyHasChanged:
protected virtual void PropertyHasChanged(string propertyName) { MarkDirty(true); var propertyNames = ValidationRules.CheckRules(propertyName); if (ApplicationContext.PropertyChangedMode == ApplicationContext.PropertyChangedModes.Windows) OnPropertyChanged(propertyName); else foreach (var name in propertyNames) OnPropertyChanged(name); }
Thank you Jonny, for your attention and response. From Rocky's book, I understood that PropertyHasChanged is also involved in databinding. That was the reason for including it after each fields changing in my set property like this:
Set(ByVal Value As Integer)
CanWriteProperty(True)
If mBaseField <> Value Then
mBaseField = Value
mField1 = ""
PropertyHasChanged("Field1")
mField2 = ""
PropertyHasChanged("Field2")
PropertyHasChanged()
End If
End Set
Now, I replaced this piece of code like this:
Set(ByVal Value As Integer)
CanWriteProperty(True)
If mBaseField <> Value Then
mBaseField = Value
mField1 = ""
ValidationRules.CheckRules("Field1")
mField2 = ""
ValidationRules("Field2")
PropertyHasChanged("BaseField")
End If
End Set
Winform DataBinding is working properly, even for Field1 and Field2 properties. And the performance is obvious!
Now, I'm trying to understand why... because from Rocky's book, a call for PropertyHasChanged - that invoke OnPropertyChanged event is required for all properties, in order to be in sync with user interface - windows form.
I will be back if I find the answer.
Marian, if you raise a property changed event with a property name, WinForms will refresh that one field I believe. If you call PropertyHasChanged without giving a property name, it will redo the databinding for ALL bound controls. I think what you're seeing is a result of removing the last PropertyHasChanged call that didn't specify a property name. I'm not sure what BaseField is, but I would expect you'd need to call PropertyHasChanged for Field1 and Field2, but it depends on what is going on in the code you're not showing.
Thanks Andy, I will check the initial implementation, adding name of property as argument to PropertyHasChanged. Like this:
PropertyHasChanged("BaseField").
BaseField means the name of property that uses mFaseField field (implementing Get and set). Later I will check and post here the part of Rocky's book that defines PropertyHasChanged, with and without parameters.
I'm not able to understand why my solution (based on validation.checkrules and without PropertyHasChanged for Field1, Field 2 Is working).
Databinding is implemented based on Rocky advice so.....
Hi Andy,
Based on information from Rocky's book, PropertyHasChanged(), without parameters, uses System.Diagnostics to determine the name of the current property, with a possible performance hit. In order to remove this issue it's necessary to use PropertyHasChanged("PropertyName").
So, PropertyHasChanged() and PropertyHasChanged("PropertyName") has the same effect, only for current property.
Using my solution, it seems that my problem regarding slow response is solved....but I don't understand the issue related with databinding. Only one call of PropertyHasChanged, with current property name as parameter is enough for sync UI with all fields changed?
Best regards.
Hi,
In Windows Forms the databinding behavior is like this:
The last one is the reason CSLA provides the BindingRefresh component to make sure the the property that was changed is also refreshed (ex the prroperty value is modified in the settter - like uppercase or lowercase)
In Xaml the
Copyright (c) Marimer LLC