Where to validate user input in MVC architecture?

Question

Java

Hello. I am writing a desktop program in Java with a GUI in JavaFX. Decided to learn OOP patterns and in particular the MVC approach. The data is stored in a file relational database. Validation of data in terms of compliance with the relational model - of course, in the model class. And where is it necessary, "by the mind", to lay checks that a number is entered in a numeric field? Where are sql injections, HTML markup and other dirty hacks filtered?
Google has a lot of examples of ASP.NET MVC or web applications, in PHP, for example. There, too, everything is not very clear to me. If we have a static HTML page, then all controllers and models are on the server side, but what if we have a lot of JS code with logic on the frontend? How is responsibility distributed between parts of the system within the framework of the MVC architecture in the case of a thick client?

Answer 1

And where is it necessary, "by the mind", to lay checks that a number is entered in a numeric field? Where are sql injections, HTML markup and other dirty hacks filtered?

In theory, all of the above refers to business rules and, accordingly, lies in the models. Those. the controller, having received some input from the user, gives this data to the model (say, "check" or "try to save"), and the model either says that everything is fine, or returns a list of errors that prevent the data from being processed.
A fat JS client can be thought of as an MV* application on its own. The server part in this case becomes a model. At the same time, some of the model's functions (say, some basic validation) can also be implemented on the JS side; after all, no one is saying that a model can't have multiple layers.

Answer 2

Let's think about what validation is and why we need it:
We need to check if pre-conditions for actions or state invariants are violated. For example - the user must always have an email - such rules can be stuffed at the level of the user class constructor. Then we will not physically be able to "create" a user without specifying an email. To make sure that the passed string is email - we can again wrap the "primitive" in our Email type, thus making a subtype of strings that guarantees us that any thing related to this type will be an email.
Rules such as "user must have a unique email" can only be checked where there is enough information. For example - a certain repository of users, or DAO. When we try to "save" we already do a check. Or we can do it by simply setting a uniqueness constraint at the database level. It's not so important anymore.
The difference here is that all this will cause errors. That is, we will not be able to drive the system into an "invalid state" but the user will not be able to get a list of errors that he made by entering some data. All he gets is isolated errors.
That is, if you look from the user's point of view, in addition to validating business rules, we also need to validate incoming data. Validation of request data, at the controller level. Then we have all the incoming data and each individual action will know what to check. And then we will be able to check all the rules and issue one list of all problems with incoming data.
In simple cases, when the data from the request is stupidly mapped to the "data model", we can already check the result. But in the case of logic more complicated than CRUD, this will no longer work. Actually, it's a little more complicated. For example, we passed a non-existent ID to a related entity. We ask for data, we get null, and the validator gives us something like "Sorry, but this thing is required." And the user is like "whaaa? Well I filled it out!" Now, if he received a message saying "The thing you have chosen does not exist" - then okay, but the vast majority do not bother like that.
In a word ... here you need to proceed not from "where it is done in MVC" but from "who needs it and what goals do you pursue."
If anything, MVC is not the whole application, it's just a way to share responsibility. The application should not know anything about the UI and that's it. That is, the validation of incoming data may well lie at the controller level, since it is he who needs to form a list of errors and push them to the form fields. On the other hand, part of the validation can take place generally outside of "MVC", somewhere inside, at the level of the domain model.
It is impossible to form the word eternity from the letters "M", "V" and "C". It is for this reason that MVC as an approach for organizing a GUI has not been used in its pure form for 20 years.