Form encapsulation of application logic?

Question

Design patterns

Let's say there is a website written in some programming language that uses the MVC pattern. All forms on the site are represented by objects whose public properties are form elements, and methods allow you to check the form for the fact of submission, validation, etc. Form data is retrieved from properties that also implement control rendering, custom validation, and state changes.
The question is conceptual and is where the application logic should be located in this case, for example, saving data from the form to the database, in the controller or in the form itself, for example, as the implementation of the onPostAndValidate method, onValidateError(), etc. In the case of processing a form from a controller, the logic for processing a POST request for each form is copied. If everything is encapsulated in a form, then there is a vague doubt about the mixing of responsibility - whether the form class will be overloaded. Here is such a dilemma. How would you recommend doing it?

Answer 1

And you add here another case when you need to add a validation rule like “unique email in the database”, or over time you decide to change the column in the database table and now keep the field length not 100 but say 200 characters - it will turn out to be completely confusing. In other words, form validation is generally closely intertwined with the model in one way or another.
You can try to do this:
All validation must occur in the model when saving. When saving, the model returns an “object of advice” which contains the result of the work: validation errors are listed, some auxiliary data (how many rows were saved or updated), if saved successfully, also the object of the entity that we save.
In the controller, the binding and coordination of the form object and the “response object” takes place

Answer 2

Perhaps you should create separate Entity classes that can be manipulated at all layers of the application.
M, V and C are "sublayers" of the UI. And besides the UI, separate layers of business logic (BLL) and data access (DAL) are often distinguished. Thus, in your MVC, you can manipulate data and then pass it as Entity objects to business logic classes, which in turn will call data access methods for CRUD operations.
This is just one of the architecture options. It all depends on the specific application, but the details would hardly fit in the question, so ... think, choose :) Or ask more specific questions.

Answer 3

Try to allocate a separate class that will be responsible for the data that needs to be sent to or retrieved from the database, and when saving to the database in the controller, request this class from the form and give it to the DB class to tear to pieces (or torment it right there).
The form as a UI element should not know about the database, but should give data in some form. The controller, as a layer between the UI and the DB, must turn the data from the UI into data suitable for the DB.
Looks like the answer is similar to the previous one (^_^)