2

In a scenario where you use an ORM to map your entities to the DB and you have setter validations (nullable, date lower than today validation, etc), every time the ORM gets a result, it will pass into the setter to instance the object.

If I have a grid that usually returns 500 records, I assume that for each record it passes on all validations. If my entity has 5 setter validations, than I have passed in 2.500 validations.

  • Are these 2.500 validations going to affect the performance?
  • If it was 15.000 validation, will it be different?

In my opinion, and according to this answer, setter validation is useful than constructors validation.

  • Is there a way to avoid unnecessary validation, since I am safe to say that the values I send to the DB when saving the entity won't change until I edit it on my system?
Improve this question
1
  • 2
    Sharing your research helps everyone. Tell us what you've tried and why it didn’t meet your needs. This demonstrates that you’ve taken the time to try to help yourself, it saves us from reiterating obvious answers, and most of all it helps you get a more specific and relevant answer. Also see How to Ask
    – gnat
    Commented Oct 23, 2013 at 10:58

3 Answers 3

Reset to default
7

Does it effect performance? Sure.

Does it matter? Ask your profiler.

Is it worse than bad data in your database? Not a chance.

Improve this answer
4
  • To know how many seconds does it affect is only using profiler?
    – Tiago B
    Commented Oct 23, 2013 at 13:02
  • @TiagoBrenck - it depends on your setup. For most scenarios, run a profiling session and then look for the validation methods in the output...
    – Telastyn
    Commented Oct 23, 2013 at 13:12
  • One curious thing, I made a test project that loaded 33.000 records, and each record was a simple entity with 4 null validation methods. The time cost with the setters validations and without it was the same...
    – Tiago B
    Commented Oct 23, 2013 at 16:49
  • +1 for "Is it worse than bad data...".
    – John R. Strohm
    Commented Oct 23, 2013 at 18:52
5

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.

P.S.

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.

Improve this answer
1
  • 2
    From my experience, with re-usability for a company's domain model in mind, it often turns out that you can't exactly predict under which circumstances a domain entity like e.g. an Invoice is valid or not. It depends on the scenario and the context within which it is being processed. It may make sense to separate "technical" (i.e. most basic, necessary, probably accessing private fields) validation from different context-based validations. For the latter, you'd rather use different implementations of a, say, Validator<Invoice> for your current unit of work.
    – herzmeister
    Commented Oct 23, 2013 at 18:36
0

If I have a grid that usually returns 500 records, I assume that for each record it passes on all validations. If my entity has 5 setter validations, than I have passed in 2,500 validations.

Only if every record in the grid has been edited by the user.

Validation only occurs on data entry. If you're just displaying records, there is no validation taking place. Presumably the data you are displaying was already validated when it was data-entered, or validated when it was consumed from a different system.

I would suggest that whatever the cost of validating a new record is, it's almost certainly smaller than the user typing in that new record.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.