✅ Does anyone know why Validator.ValidateObject only validates properties and not fields?
And is there a way to make it work with fields?
31 Replies
Why validate fields?
They're an implementation detail
So... because that's how it's written. Deep down in the bowels of the the validate object code you have ...
NB: I redacted some silverlight code from the above.
So validate object won't ever know about fields.
DataAnnotations leaves a lot to be desired. Looking at the source, you may be able to use Validateor.ValidateValue; but I"m not certain.
The same way you don't test private methods, you don't validate private fields
And if it's public it should be a property anyway
And those can be validated
I'm assuming he means public int SomeField;
which yeah, I also fundamentally disagree with, use a property.
I guess im off the mind set that one should use a field until they need it to be a property, which is why im a little confused by this limitation
You're of the wrong mindset, then
Annoyingly there is this, where validation attributes can be on fields.
There's not a large cost to use a property; introducing a property later is a breaking change that is hard to fix.
a little salty :/
but not wrong
i wasnt aware, is that because of reflection differences?
Encapsulation, changing it is breaking
yesn't, if you're deploying your whole app it's not a breaking change if you're not using reflection, if you are using reflection it may be a breaking change; if you're deploying using multiple assemblies and only a partial deployment then it's a breaking change.
fair enough, i'll switch them over
Also, for purely pragmatic purposes, every library will assume properties are public and fields are private
Fields don't get serialized to JSON, for example
Fields cannot be used in DI
Etc.
thats good to know, untill now i kinda felt that { get; set; } was essentially a more verbose way of declaring a field unless you implemented them
properties create methods, like <GetName()> and <SetName(string value)>; and fields don't; so a partial deployment creates a breaking change when updated from a field to a property.
$getsetdevolve
can be shortened to
can be shortened to
can be shortened to
can be shortened to
you can declare more explicit getters and setters, that become the guts of methods like <GetName()>, let's say if you wanted to return a default value or something.
Kinda strange thing, type.GetProperties() does not return autoproperties, but GetFields() does
unless theres something really buggy going on lol
Angius
REPL Result: Success
Result: List<string>
Compile: 463.180ms | Execution: 59.138ms | React with ❌ to remove this embed.
For reasons unknown to me, you need to specify at least two flags:
* Static or Instance
* Public or NonPublic
Otherwise, you get an empty array
i think its just a problem with my source generator
You're using reflections in a source generator?
no, im using a source generator to autofill some XML annotations, but the old generated file with the member is still a field apparently
I feel like .... that didn't use to be the case?
I can see references to it on SO going as far back as 2013
Probably even earlier
I might be conflating with something else with reflection, do you need to do that for attributes?
i fight a lot with the XmlSerializer, but anyway its a different issue :P how do i mark this as solved?
/close
thanks,