Validation concept questions

[uenluena]

Hello,

Im working on project where we use JSF in combination with Spring.

As we have custom validators for JSF i had the idea to decouple the validation from JSF, as some validations like Zip-Code etc. could be used later in some service classes, which won't have a user interface.

As a result of my brainstorming, the following structure would be needed

This would be the pojo-validator-interface

public interface Validator{
    public abstract void validate(Object o) throws ValidationException;
}

The pojo-validator itself

public ZipCodeValidator implements Validator{
    public void validate(Object o) throws ValidationException{
       // validation code
     }
}

Now to be able to use my pojo in a custom JSF validator the following code would be written. The idea is that the validate method in the JSF-validator just delegates the code to my pojo, so that i have a central pojo-based validator that could be used also out of the JSF context.

import javax.faces.validator.Validator;


public class MyValidator implements Validator {


public void validate(FacesContext ctx, UIComponent uic, Object o)
		throws ValidatorException {
	// retrieve the validator from the BeanFactory
        try{
        myPojoValidator.validate(o);
	}catch(ValidatonException e){
              throw new ValidatorException("Oooops it went wrong");
        }	
}
}

What do you guys think about this concept?

[shahnawazshahin]

I think you're on the right track. It is always good to delegate the responsibilities to a separate object or layer.

To my understanding, your POJO validation interface and implementation(s) would reside at the domain layer (along with the rest of the business rules). What I might add to this are:

1. Since javax.faces.validator.Validator already exists, perhaps your POJO validation interface should be renamed to, say, CustomValidator. This helps to avoid any conflicts.
2. Perhaps it would be useful to define your own RuntimeException instead of explicity throwing back ValidationException. This will help make Service implementations much easier in future. Using RuntimeExceptions offers flexibility over change in your implementation (for example, you don't have to explicity define at the method signature of what exceptions are to be thrown).

As we have custom validators for JSF i had the idea to decouple the validation from JSF, as some validations like Zip-Code etc. could be used later in some service classes, which won't have a user interface.

A brilliant way to handle decoupling is to have a Service layer (http://martinfowler.com/eaaCatalog/serviceLayer.html). I notice that you mention about 'service classes', which I assume would represent something like web services so that other applications can integrate with this application. This would be your Integration Gateway layer (or to cut it short, the Integration layer). All of the integration implementations would go here (be it web service, RMI, etc.).

With regards to the Service layer, these are coarse grained implementations that represent specific business tasks. In this case, the Service layer implementation would be:

package org.myapp.service;

public interface ValidatorService {

    abstract void validateZipCode(Object o);

    abstract void validateAnother(Object o);

    ..
}

package org.myapp.service.standard;

import org.myapp.domain.validator.CustomValidator;
import org.myapp.domain.validator.ZipCodeValidator;

public StandardValidatorService implements ValidatorService {

    public void validateZipCode(Object o) {
       CustomValidator zipCodeValidator = null;
       ..
       zipCodeValidator = new ZipCodeValidator();
       zipCodeValidator.validate(o);
       ..
    }

    public void validateAnother(Object o) {
       ..
    }
    ..
}

At the JSF (user interface) level, adapting to your implementation, the following is applied:

package org.myapp.application.userinterface;

import javax.faces.validator.Validator;

import org.myapp.service.ValidatorService;

public class MyValidator implements Validator {

private ValidatorService validatorService;
// Either use dependency injection, or...
..
public void validate(FacesContext ctx, UIComponent uic, Object o)
		throws ValidatorException {
	// ..retrieve the StandardValidatorService from the BeanFactory
        try{
        this.validatorService.validateZipCode(o);
	}catch(CustomValidatonException e){
              throw new ValidatorException("Oooops it went wrong", e);
        }	
}
}

Although there is a slight overahead in terms additional coding, which may seem unnecessary, the benefits outweighs. Any changes to the validation rules does not directly affect the JSF implementations, and vice versa. Also, it would be possible to manage transactions (inc. distributed), exceptions, workflow and logging more effectively.

It would be easy to expose this Service layer implementation directly, but preferably such implementation should be done at the Integration layer to control what implementations needs to be exposed.

I hope this answers your question.

[uenluena]

Thanks a lot for your valuable answer :-)

I build up the whole architecture with the structure you mentioned. For validators however i tried to decouple them as much as i can and didnt want to put them into general Validator Service's.

At the moment most of the syntax checks on a form are made in the JSF layer.
So, having the custom validators delegating the job to my pojo-validators does the job.

As soon as i see the usecase to have validations on service level, i can just create the services you mentioned and delegate the validation to my custom validator.

That would be the best approach i think. What do you think?

[shahnawazshahin]

You'll still have the flexibility to have as many custom validators when they are kept in the Domain layer. The Application layer (the JSF user interface implementation) will have access to all of the custom validators that are held in the domain layer via the ValidatorService.

Remember the Service layer is course grained, meaning that you'll have many methods in each Service implementation.

So, in this case, there will be one CustomValidator interface with many implementations from this:

Interface:
org.myapp.domain.validator.CustomValidator

That implements CustomValidator:
org.myapp.domain.validator.ZipCodeValidator
org.myapp.domain.validator.EmailValidator
org.myapp.domain.validator.DateOfBirthValidator
org.myapp.domain.validator.RegistrationValidator
..
.. and so on...

Then you have a single ValidatorService:

Interface:
org.myapp.service.ValidatorService

that will have the following methods:

abstract void validateZipCode(Object o);
abstract void validateEmail(Object o);
abstract void validateDateOfBirth(Object o);
abstract void validateRegistration(Object o);
..
.. and so on...

That implements ValidatorService:
org.myapp.service.standard.StandardValidatorServic e

As the application grows or requires change in future it is possible to extend the ValidatorService to minimise the interruption between the Application and Domain layers. For example:

Interface:
org.myapp.service.ExtendedValidatorService

that extends from org.myapp.service.ValidatorService interface, and also includes:

abstract void validateAddress(Object o);
abstract void validateUrl(Object o);
..
.. and so on...

That implements ExtendedValidatorService:

org.myapp.service.standard.StandardExtendedValidat orService

Of course, depending on the size of the application it is possible to divide the Services implementation where appropriate (but try keeping it as a few). For example:

OrderValidatorService
RegistrationValidatorService
SupplierValidatorService


Hope this helps.

[uenluena]

thx a lot for your ideas...i already took the mix of bot ideas and did and implementation that works just fine :-)

[chudak]

Validation should not throw an exception to indicate that validation failed. An exception indicates an 'exceptional' condition, not normal and expected workflow (it is pretty common for an object to fail validation, especially in the web tier).

Your validator should return a boolean indicating success/failure of validaton or you should have some kind of errors/result object that can be queried.

[uenluena]

i dont think that this is that easy...

Such an argumentation would make everything but unchecked exceptions totaly useless...

A Business Exception is catched by a developer, by knowing that it can happen...and it can happen often...

[chudak]

i dont think that this is that easy...

Such an argumentation would make everything but unchecked exceptions totaly useless...

A Business Exception is catched by a developer, by knowing that it can happen...and it can happen often...

It certainly IS that easy. You are confusing the PURPOSE of exceptions.

This is the architecture forum and fundamental architectural principles state that you DO NOT use exceptions for control flow.

There is a lengthy thread about it here:

http://stackoverflow.com/questions/7...w-an-exception

And another discussion here:

http://www.javapractices.com/topic/T...tion.do?Id=129

I could dig up dozens more that all say the same thing. It is POOR design to use exceptions for control flow....PERIOD.

As to your validation example specifically, look at ALL THE OTHER validation frameworks. Do any of them throw exceptions to indicate a validation failure?

Here's just two examples....

Commons Validator

class Validator
{
    ....
    public ValidationResult validate()
    {
        ...
    }
}

Spring MVC Validator

interface Validator
{
    public void validate(Object obj, Errors errors);
}

[uenluena]

why are you talking about control flow? non of us was talking about control flow...

I read more then enough sources about exception handling....there's not many topics in java that are more contraversial, then exception handling...

I dont share your opinion on this and think that it's a valid approach when JSF itself is catching a ValidatorException...So in any case i have to throw a ValidatorException...

You can also question their approach but then we start a religous discussion which i surely want to avoid in my thread

[uenluena]

why are you talking about control flow? non of us was talking about control flow...

I read more then enough sources about exception handling....there's not many topics in java that are more contraversial, then exception handling...

I dont share your opinion on this and think that it's a valid approach when JSF itself is catching a ValidatorException...So in any case i have to throw a ValidatorException...

You can also question their approach but then we start a religous discussion which i surely want to avoid in my thread