mikeg22 wrote:
There is a block of code I would like to run every time a field value changes. PostFieldValueSetAction is perfect for when fields are directly set, but this is not called when SyncFKFields happens after an entity reference property of an entity changes...OnPropertyChanged is called, but this is only called for the last fkField in the relation, and overriding OnPropertyChanged in CommonEntityBase will just tell me that a "property" changed, not a field, and I would have to spend a lot of processing in order to find out of if the propertyName is a real field or not.
So, 2 questions I guess:
1. Why isn't SetValue called in SyncFKFields? Without this, ValidateValue and PostFieldValueSetAction are never called even though a field value has changed.
This is by design. The reason is that the FK sync should be automatic and without validation and above all: without value conversion (which is also possible in that pipeline). After all: the sole purpose of this action is to set the FK field with the exact same value as the PK field. If validation would happen, it might be the validation would reject the value and the save would probably terminate. It's not a big deal, read on
- OnPropertyChanged is called, but why only for one of the fk fields in the relation?
The reason this is important to me is that I need to assert some business rules when an entity reference is changed, but there doesn't seem to be a natural place to hook into this.
There is a facility for this purpose
-> OnRelatedEntitySet and OnRelatedEntityUnset
these methods are called when a related entity is set/unset. You can use them to run business logic when a related entity is set. You can override them in a partial class of the entity, they're protected virtual and empty by default.