Can affect performance?
Sure, it will.
If you are validating anything at all you got an overhead there. Sometimes this overhead is significant, other times it is negligible.
Should I validate on the setter?
If validating on the property setter is hurting your performance maybe you should only perform the validation when strictly necessary, like when persisting it in a database (something like a
isValid method). The downside of this approach is that you may have invalid objects lying around.
There is also a third school of thought here:
- Mutable objects that are never invalid (always validating on the setter, like your scenario)
- Mutable objects that can be in a invalid state (validating only when necessary, like I said above)
- Immutable objects that can't be invalid (if it is invalid you don't construct the object at all)
One downside with the first, the one that you are currently using, is that you might perform the validation when it's not necessary.
They all have pros and cons, which one to pick depends a lot of your scenario and your (colleagues) programming background.
Should the validation be performed on the object itself at all?
This is one is even more debatable. Separating the data from the business logic is often referred as anemic domain model. A famous objector of anemic domain model is Martin Fowler, which in this particular subject I disagree with him, but that's ok, it's my opnion :)
I'm simplifying way too much here but the main difference between letting your domain anemic and not is that one is more compliant with pure theoretical OOP and, at first, requires less effort to design and maintain; the other does better separation of concerns and it's way better when dealing with concurrency (since the objects are stateless).
This topic is a great food for thought. I suggest you to leaving everything as it is if you are on a more problem-solving scenario; big changes on the status quo might not be healthy if the time isn't right.
Being specific to your ORM, depending on the language or framework you are using, your ORM may find a way to serialize/deserialize without using getters or setters.