At which layer validation should be done in a real enterprise Java based application?

Question

I have worked as a developer in few enterprise applications mainly based in Spring Framework and Java EE (mainly EJB's); but not at all the layers (view layer is the least I have worked upon)

Considering a multi-layered application (Client layer, business layer, data layer etc) at which layer the data validation should happen?

I have heard of Bean validation API viz: JSR 303 ; but the validations are performed in the Beans, that is server side (If I understood correct).

So in real applications where the validation should happen? Should some validation happen in client layer itself (for example if the view technology used is JSP, should the validation happen in JSP)? If so then what is the advantage of JSR 303 .

It also doesn't make sense to have the data travel from client to server to be rejected because of validations, I am not clear what is the proper approach on the validations.

Any explanation in understanding this is well appreciated.

Answer 1

Normally, there are 3 layers in an application. Model Layer, Control layer and View layer. Each layer has it's validation logic.

View layer check the validation of user's input data. This check is helpful to user experience and server's performance because it can point out user's invalid input early and avoid of invalid calling of server's interface. The check in view layer should be mainly about user's input check(for example: email format check, password format check etc.).

Control layer check is necessary too. This check can avoid of illegal calling of server's interface. For example, login token is missed or invalid in http request parameter.

Model layer check is mainly about data validation. View layer checked user's email format, and model layer will check whether the email is registered in application(maybe be the user data is stored in db or cache).

In a word, each layer has it's responsibility and it should do it's data validation respective.

Answer 2

You are correct, Bean Validation API performs validation at the business logic layer, not the client's. It is also correct that in general, data validation should happen as close as possible to the client, preferably at the client side itself.

But sometimes, you just cannot do it there, so you need server-side validation. For example, how can you verify that a login is already taken in a signup page?

Sometimes validation even goes deeper to the data layer. Data integrity constrains, for instance, are data layer validation (referential integrity, nullability, ...).

In conclusion, data validation should be performed at the client side when possible, but sometimes it cannot be done there. So you have to do it in the server-side in spite of the cost of data travelling between client and server.

Answer 3

Since "Validating input received from the user to maintain data integrity is an important part of application logic", as per my knowledge, web developers are always encouraged to have 2 step data validation ie in UI as well as in the business logic. Let me brief you.

1. Advantage of client side validations is that you have control to warn the user where ever needed, and to show related messages immediately. But remember to avoid complex logics such as date comparisons as validations because at the backend you will have enough freedom to validate on various constraints.
2. Its always better to perform backend validation typically on the business layer which can become the strongest part of your application. This ensures flawless outputs, remember to throw custom exceptions which makes the application look better and make use of existing methods for validations { ex. isDigit(), isEmpty() etc}.
3. At the data layer level, try to minimise validations but sometimes we have to include them if there is dependency on other services etc.

Regarding JSR 303, the bean validation, it helps as a stretching hand to simplify the validation of user input fields which are mapped to beans { typically in Spring based applications with REST}

And regarding your doubt " It also doesn't make sense to have the data travel from client to server to be rejected because of validations " .. it might look so, but its really important to have the flow this way to handle validations involving complex logics and to exceptions better.

Answer 4

I think that talking about validation is to talk about an approach not about a solution.

An approach could be to have for any layer its own validation. Another approach is to have an application agnostic validation. The choice to the former or to the latter one depends on various factors: application complexity, layers design, maintainability, layer reusability.

JSR303 is a type of validation: bean validation.

Others validations can be:

• check against any kind of injection
• check for authentication/authorization

About reusability: if you call a business layer which rely upon client side validation then a call B2B can't use the validation.

Apart from these considerations there are good advices to follow. For example don't trust client side validation .

A client side validation is useful to improve user experience but should not be used as a substitute for server side validations.