Where should you validate / misinform data?

I am creating a traditional MVC application. I have a / lib folder that defines functions that deal with database operations and deal with external APIs. When processing user input, where should I validate the data? Should I validate it in the route controllers and then send that validated data to the database function? Or do I not need to check in the route controllers and whether the functions in the / lib folder do all the checks?

+3


source to share


2 answers


For me, the most natural place in the model is because it contains data. The GRASP Expert Principle says that you must assign responsibilities to an entity that has the information to fulfill them.

We can argue that a controller can have all the information (data) needed to validate, but for me, controllers should be lightweight. Moreover, I believe that "all information" means not only having data that you have to confirm, but also knowing its format and what the model is about. The controller can know how the data that a particular model needs should be, but that model can also be used outside of that control area, so it shouldn't rely on validation of the controller, as the model (almost) has one last chance to detect invalid data (you can and must also do this in the database, but the data must be validated and sanitized before they enter it, although there is usually a direct match between the database schema and validation.which you have to do in the model).

Every time you perform CRUD operations on a model, you will probably have to validate the data, and you will be sure that your data is almost always correct. What's more, the controller can also change the data that then goes into this model, so even if the controller has checked this before, it can result in invalid data.

However, think about it. The controller can change the data and it actually takes a long time to do it. It is unusual to always have a straight map between fields in the form and the model, and sometimes you will have inputs that have nothing or little to do with any model, so you have to test them outside the model. For example, think of the "Repeat Password" field. This has nothing to do with the model! Only the "Password" field needs to achieve this.

Other people will say they prefer and which can fit better than rich models in some scenarios, but they also have some drawbacks and rich ones are best overall.



You should also consider client side validation (like JS) so that you can give it quick feedback on what it is doing instead of sending data to the server for validation and then waiting for a response or even loading the whole page again !

One good way to do this is to use a regular expression, because you will have similar expressions between the different languages ​​you use, although more often than not this will not be enough. Or better, you can use JS everywhere with Node.js and forget about this problem completely.

This may not be the answer you were looking for, but there is more than one correct way to do the validation as it is different for each application. In most cases, validation should be done in different places, doing the same validation in some different layers of your application, and different validation between some others.

There are more questions on StackOverflow on this topic, so you can check them out to have different opinions from other people:

+2


source


One of the best approaches I've seen is to define services and layer validation on top of them using decorators. If validation errors are thrown, a custom exception is thrown containing validation errors, which are caught and handled by the controller and sent back to the client.



Controllers need to be thin and deal with things like requests and responses, not business logic. Whichever approach you take, I would suggest trying to disconnect it from your controllers.

+1


source







All Articles