When developing my interfaces (contracts) and the concrete implementations of them, both the data models as well as repositories, I find myself questioning where the validation logic should go. Part of me (which tends to win out) says that the class itself should be responsible for it’s own validation (string max length, date buffers, etc), but the other part of me says this should be moved out to the repository because depending upon the persistence store, these values could change based on your repository implementation.
I think there is some validation that MUST be done at the class level and think it should probably be kept together and not change even if the repository does, which is why I tend to keep it in the class.
I am all about putting in UI validation but this is never enough since much of the UI validation can be bypassed.
Curious what people think and the reasoning behind it.
Validation rules should be defined at the class level in an abstract fashion that can both 1) be run in the class’s native environment 2) be rendered as rules for other dependent environments, such as UI scripting or repository procedures, as needed.
This gets you the logic centralized where it should be, in the class, and ancillary validation in the UI and wherever else — easily maintainable since it’s derived from the class rather than being detached logic living in a disconnected location. All-around win.