.net data-binding events change-tracking

.net - INotifyPropertyChanging y validaciones: ¿cuándo elevo PropertyChanging?



data-binding events (3)

Como comentario aparte: PostSharp tiene la interesante capacidad de implementar automáticamente INotifyPropertyChanged, como ese .

INotifyPropertyChanged es bastante auto explicativo y creo que tengo claro cuándo plantearlo (es decir, cuando termine de actualizar los valores).
Si implemento INotifyPropertyChanging, estoy tendiendo a plantear el evento tan pronto como ingrese al setter u otro método que cambie el estado de los objetos y luego continúe con las protecciones y validaciones que puedan ocurrir.

Por lo tanto, estoy tratando el evento como una notificación de que la propiedad puede cambiar pero aún no se ha modificado y puede que no termine de cambiar correctamente.

Si los consumidores del objeto están usando esta propiedad (como vamos a decir LINQ to SQL utilizando el evento para el seguimiento de cambios), debería esperar y solo plantear el evento una vez que haya validado que los valores que se me dieron son buenos y el estado del objeto es válido para el cambio?

¿Cuál es el contrato para este evento y qué efectos secundarios habría en los suscriptores?


Si a su objeto se le asigna un valor que no es válido para la propiedad y lanza una excepción, no debe generar el evento PropertyChanging . Solo debe plantear el evento cuando haya decidido que el valor cambiará. El escenario de uso típico es para cambiar un campo simple:

public T Foo { get { return m_Foo; } set { if (m_Foo == value) return; //no need for change (or notification) OnPropertyChanging("Foo"); m_Foo = value; OnPropertyChanged("Foo"); } }


Si desea evitar implementar INotifyPropertyChanged por completo, considere usar Update Controls .NET en su lugar. Esto elimina casi todo el código de contabilidad.