I read the book, but not yet the ebook covering 3.0. So possibly i am asking things explained in there.
Why does ObjectStatus declare it's DependencyProperty-s as private whereas public seems the standard?
Why are the setters of IsDeleted, IsDirty etc calling OnPropertyChanged manually. Isn't that implicitly performed by the DepedencyProperty class?
Why are the setters of those properties public?
Why is Refresh called in response to any change in the business object instead of Binding the DependencyProperty-s to the corresponding ones of the DataObject in the DataObjectChanged method? This I tried, but unfortunately no PropertyChanged event is raised when e.g. IsDirty changes. That is, OnUnknownPropertyChanged is called. I understand the implementation has changed in version 2.1 but I guess calling OnPropertyChanged with a String.Empty argument does not trigger a WPF Binding.
It has been perhaps 18 months since I wrote this code, so hopefully my answers are accurate :)
The static fields could be public or private - public for WF support, any other scope works for WPF. I created the class for WPF, so the static fields aren't used by anyone. If they need to change to public at some point that's something I'll do.
If I recall correctly, I had to call OnPropertyChanged manually to get the correct behavior. I don't remember if I discovered why that was though...
I'm not sure why the setters are public. There may have been a reason, or perhaps not - I don't recall for certain. They probably shouldn't be public - assuming making them non-public wouldn't have some negative side-effect.
Notice that Refresh() detects changes in the individual Is___ property values. These properties do not raise their own PropertyChanged events from the business object because they are not bindable (they are marked as Browsable(false)). It is not valid to raise PropertyChanged events for non-bindable properties.
So ObjectStatus infers that the Is___ properties may have changed each time any other property changes.
In fact, the only reason for ObjectStatus at all is because the Is___ properties aren't bindable. If they were bindable then the XAML could just bind to them directly and be done with it.
The Is___ properties aren't bindable because having them bindable makes UI creating difficult when using the drag-and-drop capabilities in Windows Forms and the auto-detect capabilities in Web Forms. If they are bindable, then every time you use the RAD features of VS you end up manually removing those properties from the UI - not fun.
WPF doesn't (yet anyway) have the same kind of VS designer support. So it could seem that for WPF I should have a separate version of CSLA where these properties are bindable. Obviously forking CSLA for WPF is not a desirable scenario for many reasons. But on top of that, I am lobbying for Microsoft to add decent designer support for WPF data binding into VS. And based on their good support for Windows and Web Forms it seems reasonable to think that we will have good designer support at some point in the future - at which point the same issue would come up and the Is___ properties should be non-bindable :)
Copyright (c) Marimer LLC