Search for existing suggestions

Ability to intercept and cancel changes to properties

(Note that the original description of this idea talked about making PropertyChangingEventArgs cancellable. Although this is an interesting request, it is not a change we could implement in EF. In fact, there is probably not way it can be implemented in .NET without defining a new standard interface for change tracking)

Rather than declining the idea, I am renaming it to capture the essence that is still potentially applicable to EF: provide a hook that can be used by an application or library to intercept what happens whenever EF detects that a property of a tracked object is being changed and allow for the change to be reverted.

Original Description:
When overriding the PropertyChangin in an entity object, there is no advantage as you can't stop the process from the handler (the partial OnPropertyNameChanging method can be used to throw an exception), since you have no way to guess the attempting set value which makes the PropertyChanging event almost worthless.
In addition, exceptions cost much more performance + is very rough compared to flagging e.Cancel.
So my suggestion is that PropertyChangingEventArgs should:
1) Provide the attempting set value (i.e. the value that the property will be set with if e.Cancel remains false)
2) Inherit from CancelEventArgs (sibling in System.ComponentModel namespace)
3) Provide the object who fired this event, so it can be handled in an external layer.

In this way, it will be much easier to globally validate entities without the need to implement individual OnSomePropertyChanging partial methods.
Please vote on the connection I posted about as well:
https://connect.microsoft.com/VisualStudio/feedback/details/586560/propertychangingeventargs-should-inherit-canceleventargs-and-should-include-the-candidate-value

8 votes
Sign in
(thinking…)
Sign in with: facebook google
Signed in as (Sign out)

We’ll send you updates on this idea

shimmy shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

3 comments

Sign in
(thinking…)
Sign in with: facebook google
Signed in as (Sign out)
Submitting...
  • shimmy commented  ·   ·  Flag as inappropriate

    @Tamus, I believe you're right. It shouldn't inherit from CancelEventArgs.
    This will lead to inconsistency having the user cancel the property-set without notifying the caller.
    BUT, but, but what really really important is, that the candidate value should be provided at the OnPropertyChanging event, then will throw an exception instead of cance, which makes more sense.

    *SO FOR CONCLUSION*:
    My original post should be edited and be:
    "Provide the candidate value at the OnPropertyChanging method and in the PropertyChangingEventArgs"
    - so user knows the what the candidate value is, otherwise, the PropertyChanging event makes no sense (getting the candidate value is a tough job and is very performance-expensive).

    Please see this connection:
    https://connect.microsoft.com/VisualStudio/feedback/details/632384/propertychangingeventargs-class-should-provide-the-candidate-value

  • TamusJRoyce commented  ·   ·  Flag as inappropriate

    Please refrain from voting this up any more. First, use reflection to get the object located when OnPropertyChanging fires. Then again, use reflection to get the object located when OnPropertyChanged fires. Notice the endings. You can then compare the two to see the change.

    It should not inherit from CancelEventArgs, as not only would this break .NET 1.1 to .NET 4.0 (or whatever version this is implemented) comparability, but the property that gets canceled needs to notify whatever is setting it that it didn't get set. And the only way to do that is to throw an exception (performance, yatta yatta yatta...bad!).

Feedback and Knowledge Base