Writing a web application we have many places where validation takes (or potentially could take) place: - front-end application form - front-end application service - back-end application view function - ORM object

It would be nice to make sure that front-end form validation matches back-end data format expected by back-end and finally that it matches ORM expected format.

Example: Let's say we have a registration form and I want the "username" to meet some requirements:

  • min length
  • max length
  • no space
  • no special characters
  • etc...

My question is: Should my ORM model reflect those requirements? Should I use some validator on my model to make sure that if I create a database object User and set its username field then it raises validation error if it does not conform mentioned conditions? Or maybe it is related to business logic and should not be checked at this level?

The thing is that I would like to have consistent validation across my application. I.e. if I have a limitation to the number of characters in username than I would like to have the same limitation in my JSON schema protocol to correctly validate API requests and later to have the same "constraint" on DB ORM object. Currently, I have defined schema that I use to test: - front-end registration form - front-end outgoing requests (from the front-end to the back-end API) - back-end input requests

What I've left are ORM objects. But I wonder what level of validation should I have on ORM objects. Can I assume that if an object passes validation against JSON schema then it should pass ORM object validation?

An example against it: Let's assume I don't want to allow the user to set a weak password on registration but I'd like to have an admin view that can set any password.

  • 1
    Thanks for this question, i am not much aware of ORM model and the type of web architecture model you are talking about. Could you guide me to some articles to read more about this or try to explain this architecture in a more simplistic form? – PDHide Mar 27 at 22:51
  • 1
    @PDHide I have updated my question. Is it more clear now. I'm looking for a reason why do not validate ORM objects so strictly or maybe on contrary, i.e. that I should validate the data even if it's duplication of my "view" (meaning web application function that handles requests) request validation. – user2146414 Mar 29 at 8:52

When it comes to ORMs or really anything I am using to model behavior, I aim to create models that are going to protect the system I am writing tests for the most.

This usually means I am modeling whatever backend database or document storage system the software is using. Why?

Regardless of what a user can do or an API is written to do most backend systems have hard restraints that are determined by the datatype they are storing. These column restraints should be respected and modeled by your ORM objects.

This ensures that even if something were to make it through your JSON validation it would surface an error before attempting to perform an action on your database.

The drawbacks of this is having to be more attentive to scheme changes.

@PDHide Take a look at SQLAlchemy for Python or ActiveRecord for Ruby.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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