views:

380

answers:

3

What is the best way to implement a validator in Spring that accesses a DAO object but needs to return different error messages based on the DAO error? Should the DAO method throw different exceptions that the validator turns into proper error messages? Should the DAO return an enumeration so the validator can handle each return type separately if necessary? I suppose the validator can pass the org.springframework.validation.Errors object to the DAO, but that seems to tie the two classes too closely together.

I believe the best approach is the enumeration approach to avoid the overhead of exceptions. Is there another way I should be considering?

Update

Actually, the enumeration would probably have to be a reference passed into the DAO as that method had to return the actual object. Is this still the best approach?

Update 2

The issue is I need to retrieve information from the database in this particular case, not store it. In the validation class, I was checking if the value already exists (which is why it needed the DAO), and if it already exists that is an error that I would show to the user on the page. I do need to validate that all fields on the form were filled in, so maybe that's the only thing I use the validator for. Then, how do I handle the error where the value already exists in the database? The DAO is the only thing that will know that - what is the best way to communicate that error from the DAO to the web layer?

The DAO method is currently returning the user object it is retrieving from the database - I can return null if there is an error, but that doesn't give me any granularity into the error details - it's essentially a boolean at that point indicating if the record was found or not, but not why.

A: 

I suppose the validator can pass the org.springframework.validation.Errors object to the DAO, but that seems to tie the two classes too closely together.

I'm not understanding this. Why would you pass Errors to the DAO?

The point of validation is to prevent bad data from ever getting within sniffing distance of your database. You should be sending a response back to the source of the request informing them about any Errors you've encountered.

The only reason I can think of for passing such a thing to a database would be to track requests and responses as an auditing/tracking function.

If there are errors, the use case is done. The user needs to be informed, not your database.

UPDATE:

If you're checking something like a username that has to be unique in a database, by all means do that check. But I'd do it as an AJAX call, as soon as it was entered, and if it already existed I'd simply tell the user so.

DAO should not know about web tiers. Bad design - too coupled.

Let the web tier inquire through an intermediary. The intermediary will make the query and send back the appropriate result. Your web page should have a controller and/or service of some kind that can be that intermediary.

duffymo
I need to retrieve information from the database, not store it. In the validation class, I was checking if the value already exists, and if so, that is an error that I would show to the user on the page. I do need to validate that all fields on the form were filled in, so maybe that's the only thing I use the validator for. Then, how do I handle the error where the value already exists in the database? The DAO is the only thing that will know that - what is the best way to communicate that error from the DAO to the web layer?
David Buckley
Validation is to make sure that data coming into the database is valid from all points of view. If you do a query and it doesn't exist, that's not the place for validation. If you're checking to see if something like a username that has to be unique in a database, by all means do that check. But I'd do it as an AJAX call, as soon as it was entered, and if it already existed I'd simply tell the user so. DAO should not know about web tiers. Bad design - too coupled. Let the web tier inquire through an intermediary. The intermediary will make the query and send back the appropriate result.
duffymo
A: 

Checking the database in your validator is a valid thing to do.

I am a bit confused about what sort of errors you are expecting your DAO to return though. Typically it will either return the requested object or NULL, and it is up to the caller (your validator) to know the reason why.

If you need to check that multiple fields don't already exist in the database, then just make multiple DAO calls.

Daniel Alexiuc
+1  A: 

Validator accessing DAO is valid.

I Would suggest throwing exception over passing enumeration.

If given one more option I would suggest not throwing exception but returning null.

You may design your DAO methods in such a way that they would return the populated object if available, if not just returns null.

Take following example:

DAO layer :

 class UserInfoProvider {
    public void createUser(User user) throws UserCreationException {
      // throws UserCreationException when something goes wrong while updating database
    } 

    public User findUser(String username) {
       // return user object if found

       // else just return null
    }
 }

Validation :

class UserValidator {
     public void validate(command, errors) {
        String username = command.getUsername();
        UserInfoProvider userInfoProvider;
        User user = userInfoProvider.findUser(username);
        if (user == null) {
          errors.rejectValue("username","User not found");
          return;
        }
     }
  }

You might consider using Spring security when you are using Spring MVC.

novice