OOP design - validation when validation means hitting the database to check

Let's pretend we're talking about an HTML complaint form, one field of which is a product list from the company catalog.

I gather that validation usually (always?) goes in its own class.

I also gather that it's good practice to have gateway classes which can handle all the database queries internally, so when I save my complaint from my complaint form I don't have to worry about the database details.

But what about validation that requires accessing the database - for example checking that the product is actually a product we have (and not someone tampering with the form). This can only be done by finding a match in the database... but my database is abstracted behind my gateway.

Do I add validation logic to my gateway? Do I create validator gateway classes? Do I empower my validator with database logic?

EDIT - attempt to clarify...

1. customer clicks link to complaint form
2. HTML comp开发者_开发问答laint form is built with a <select><item></item></select> dropdown with X products from our fictional company catalog
3. Customer completes form and Submits // Wiseguy alters HTML so product is "Schweddy Balls" and submits
4. Form class validates simple things like date, all required fields have data, email address, etc.

at step 4, in order to validate that the product being complained about is legit, you'd have to hit the database's product table to see if it's still a valid datapoint. Should that logic go in the form class, the gateway class, or somewhere else? putting it in the form class breeds dependencies, does it not?

Validation should, oddly enough, not be done directly through a Validation class. A model object's class (in this case probably Complaint) should include the Validation class and the validations should be done in there. Since the Complaint has access to all Complaints, validation methods can use the methods of the Complaint class, or call another model class if needed.

When you say "gateway" to the database, I believe you're talking about on Object Relational Mapping (ORM), which allows model objects, like a Complaint, to abstractly talk to the database. The ORM should have no knowledge of the structure or specifics of the application, it should only be an abstract API for objects to communicate to the database or other backend.

Surely my response does not cover everything, so further questions/clarifications welcome.

It's usually good practice to store valid data, only. So, one necessarily writes a validator on the server-side to ensure that requests are valid and only valid data gets put into the database, and as an optimization one typically validates on the client side (e.g. in JavaScript) so that the user is informed of invalid input without needing to submit the form and without needing to make a roundtrip. Doing the validation as part of the database write, allows subsequent reads to be done trivially with no checks.

I don't know the specifics of what counts as "valid" for you, but you can probably save a lot of database lookups with caching. Perhaps you could give some more information about your requirements?