Custom property setter logic

Jul 13, 2011 at 7:42 PM
Edited Jul 13, 2011 at 8:15 PM

Hi! This is a very useful library, especially for those projects with huge domain models.

I have a question. I'd like to implement a specific type of setter logic for one or more properties of my entity class, mostly because I need to validate the data being set and, if it violates the entity integrity, I just don't want the INotifyPropertyChanged to be fired and the field value should remain unchanged.

How could I reach this goal? Maybe I could in some way override the "SetValue<T>" method in one of my concrete entity class and put inside some logic?

Thanks in advance.

Massimo

Coordinator
Jul 15, 2011 at 9:01 AM

Hi Massimo,

Yes, you could possibly override SetValue<T>.  (I expected people to do that, when I designed ActiveSharp).  Another option is for you to put your validation logic in the property setter itself, and only call SetValue if the new value passes your validation.

Having said that, there are at least three different patterns for validation:

  1. Throw an exception if the value is bad
  2. Accept the bad value, but report a validation error from the object.  (E.g. validate objects before saving them, rather than at the time the properties are set)
  3. Simply don't do the property change (as in your suggestion)

Personally, I've found #2 to be the most effective on the projects that I've worked on.  I've never used #3 and I don't think I've personally seen anyone else use it.  But, if you do need to do number 3, then you certainly could with ActiveSharp.

John

 

Jul 15, 2011 at 3:33 PM
johnrusk wrote:

Hi Massimo,

Yes, you could possibly override SetValue<T>.  (I expected people to do that, when I designed ActiveSharp).  Another option is for you to put your validation logic in the property setter itself, and only call SetValue if the new value passes your validation.

Having said that, there are at least three different patterns for validation:

  1. Throw an exception if the value is bad
  2. Accept the bad value, but report a validation error from the object.  (E.g. validate objects before saving them, rather than at the time the properties are set)
  3. Simply don't do the property change (as in your suggestion)

Personally, I've found #2 to be the most effective on the projects that I've worked on.  I've never used #3 and I don't think I've personally seen anyone else use it.  But, if you do need to do number 3, then you certainly could with ActiveSharp.

John


 

Hi John,

first of all thanks for your prompt reply!

Actually I haven't yet decided wich strategy to adopt for dealing with the validation of data. Maybe your suggestion is the best choice, but I think it depends also  on the perspective you take. For example, from the user interaction point of view sometimes it's desirable that the user is imformed as soon as possible about a "bad" submitted value, not just when it clicks the "save button".

In the case the project is based on MVVM (for WPF presentation layer for example), this is resolved by taking the data validation at the ViewModel, implementig for example the IDataErrorInfo interface inside the ViewModel object. In this case is possible to separate the validation and maybe not to propagate the bad value to the data model entity.

In my case I'm working on a Windows Form project and, for the moment, the presentation layer is often pupulated directly with data model entities or in some cases with sort of data tranfer objects created just for the presentation.

In a few days I'll try to implement your lib into my project, so if I'll have other interesting questions I'll write here again! Thanks for patience...

Massimo