Understand validation and data binding - Spring Tutorial

- [Instructor] Validations is a must implement requirement for a web application or in general for any kind of application. Why do we need validations? In a web application, for example, you have a lot of HTML forms where the user can enter data into input fields on the HTML. Let's say, for example, a user registration form. It is necessary to verify the correctness of this data before processing it. Otherwise, we'll end up saving bad data in our persistent stores. Validations can occur both on the client and the server side. You can run a bunch of validations using JavaScript code on the client side. However, when the data gets submitted to the server side there is a chance that it may be overridden. This means that we should have another layer of validations on the server side too. Now, whether the validations should be considered as a part of business logic or not is a point that is argued amongst many developers. Validations can be cosmetic or business. Business validations are tightly coupled to the application logic, so they would mostly occur on the server side. Cosmetic validations, however, like verifying the format of an email or date of birth, these can occur both on the client and the server side. Now spring MVC provides a very good design for validation that you can use not only in the web layer but any other layer of your application as well. Let's take a look at a couple of approaches that Spring MVC supports for validation. The first one is Bean validation. Spring MVC entirely supports this approach that actually comes in from the Jakarta validation specification. The second approach is by fulfilling the validator contract. Now, this is specifically a part of the spring MVC framework. Let's take a look at these in detail. Bean validation is an approach where you declare constraints on the properties of your Java Bean or the domain object. Each of these constraints correspond to the kind of validation that you want to run for that particular property, and these constraints come in from the Jakarta validation specification. To do this, you need to annotate your Bean property by the corresponding annotation that comes in from the Jakarta validation spec. For example, if you want that your username should never be null, then you can insert an annotation called @NotNull on the username property inside your Java Bean. Another example is where you want to restrict the size of your name field. Then you can use annotations like @size, @min, @max and so on. There is a host of annotations available in the Jakarta validation spec for you to carry out any kind of validation on the Bean properties. You could also develop your own constraint which holds very specific validation logic. You can then insert that constraint on the particular Bean property for which the validation is intended for. The second approach is the validator contract. As I said earlier, this is very specific to the spring MVC framework. So the framework has a validator interface dedicated for validations. You as a developer will have to implement the validator interface, and for this you need to define two methods. The first one is supports. This specifies the Java Bean or the domain object whom the validations are being carried out for. And the second one is validated where all the validation logic should go in. The validator interface always makes use of an errors object. So this is another API in the MVC framework. Whenever the validations fail, this errors object is populated. So you can carry this errors object on your HTML to display the error messages. It is true that you can create one validator implementation for validating all the properties of all your Beans but that's not a good thing to do. The best practice is always implement one validator class per Bean of your application. So for example, if you have the person Bean and within that you have reference to the address Bean, now you can write one validator implementation which validates all the properties of the person and the address class. But instead of that, the best practice is to create the person validator implementation to validate fields of the person Bean and an address validator implementation to validate the fields of the address Bean. Doing so you can actually end up reusing the address validator Bean for any other flow in your application. Along with validations, there is also the concept of data binding in the spring MVC framework. So as the name suggests, it helps you to bind data to variables or Beans or domain objects, or POJOs, whatever you want to call it. This is the data that you will use for further processing inside your controller. Now, data binding can be done in many forms. You can bind your form fields to a respective Bean or a domain object. For example, a user registration form could be bound to a user bean. You can also bind request parameters and we have already seen this in a search use case. We did bind the incoming search string to a string variable inside the controller method. Additionally, you can also bind incoming headers and cookies to respective Beans or objects for further processing. So the validator and the data binder together form the validation package inside the Spring MVC framework.