Exception handling (Dao or Service ?)

[gonzalad]

Hello,

I'm really sorry to ask this basic question :

Supposing I'm checking database constraints in java code, where should I check them and where should I generate the corresponding exception :
In the Dao component or in the service component ?

Thank you very much for your advice on this matter.

For instance I have UserManager and UserDao, if I'm going to check in service, I will have :

public class UserManagerImpl implements UserManager {
public void save(User User) throws DuplicatedUserNameException {
        if (dao.isUsernameExists(user.getName()) {
                throw new DuplicatedUserNameException ("Duplicate username.");
        }
        dao.save(user);
}

}

If I'm checking it in Dao, I'll have this sample code :

public class UserDao implements UserDao {

public void save(User User) throws DuplicatedUserNameException {
    User lExisiting = (User) getJpaTemplate().find (User.class, user.getId());
   if (lExising != null) {
        throw new DuplicatedUserNameException ("Duplicate username.");
    }
    dao.save(user);
}
}

[Marten Deinum]

I think it depends on the exception. In your case I would handle it in the service, it is businesslogic which belongs in a Service not in the dao.

[gonzalad]

Thank you very much for you insight !

So, this means that if another service (say OrderManager) needs to execute some operations on Users, it would need to use UserManager and not UserDao, is it ?

So 'very generally' speaking Daos are private to a service, and functionnality reuse must be done across services ?

For instance (this sample is silly but...) :

class OrderManager {
   
   public void placeOrder (Order order) {
       User lUser = order.getUser();
       if (lUser != null) {
            getUserManager().save (lUser);
       }
       //...
   }
}

}

[karldmoore]

Well exactly that's the crux of the problem. If you don't use the services you can bypass the validation, probably not a good idea! This blog might prove useful, it was in response to a thread on the architecture forum a while ago.
http://blog.interface21.com/main/200...my-first-post/

[gonzalad]

Sorry for being late, I had some problems connecting to the forum.

I had already read this interesting blog.

But checking constraints using Validators has 2 nasty consequences :
1 - performance : from my point of view validation (in Validator) should perform well in order we can call the validator in any layer of our application (presentation / service / dao).
2 - generic exception mecanism : I think generating something like ValidationException or anything else containing the interface Error is less explicit than throwing a typed one (for instance DuplicatedUserException). I think I would like sometimes to catch this kind of exception.

So I was going to use Spring Modules Validator Bean for basic validation (length, regexp, ...), but I was going to do custom code for checking integrity constraints.

I was going to execute the ValidatorBean in each one of my layers (at least presentation and service).

My remaining point was where should I check integrity constraints.

If using the DDD approach I think I should check this constraint in the repository (ie. DAO), but I'm going for a really mainstream approach, so I don't know...

Perhaps Service should be better - more easily understandable :
- just annotate your domain classes for basic validation constraints.
- check your integrity constraints and check presence of obligatory parameters in your service.
- if you want to reuse a piece of code, just reuse your service.

Really basic approach, but should work for most case no ?

If you have a better one, I'm really interested.

And soory for my awfull english

[Manuel Palacio]

Aren't you using this?

[gonzalad]

Yes I'm using Hibernate Validator but through Spring Modules.

Hibernate Validator is great for me (simple to use and expressive).

If I'm using Hibernate or Seam, Hibernate Validator is automatically applied.

I'll be using Spring Modules (class ValidatorBean with Hibernate extension) in order to :
1 - apply validation aspect on service calls (execute hibernate validator annotations on the parameters).
2 - to be able to do custom validation code which cannot be expressed on a domain object but depends on a use case (so programmatic validation).
3 - [not really usefull for the moment] - be able to use others validation extensions (not only hibernate validator annotation, but also Spring annotations such as Valang, ...)

The two solution work great together, I'll just need to modify Spring module HibernatePropertyValidationAnnotationHandler to use Hibernate messages.

So, the only thing that remained fot me was checking integrity constraints (not really the scope of hibernate validator or Spring Modules in my own opinion) - and to see where I put this code (i.e. does the domain object I want to create already exists or not, ...).

[karldmoore]

So, the only thing that remained for me was checking integrity constraints (not really the scope of hibernate validator or Spring Modules in my own opinion) - and to see where I put this code (i.e. does the domain object I want to create already exists or not, ...).

You are dealing with simply business rules, e.g. you can't have two user's with the same username, choice between DAO and service, I'd say service.

[gonzalad]

Thank you very much for your appreciated help.

So I'll follow karldmoore & mdeinum advice and put this kind of validation in service layer.

[karldmoore]

Thank you very much for your appreciated help. So I'll follow karldmoore & mdeinum advice and put this kind of validation in service layer.

You do need to make sure everything talks to the service however. Otherwise, you can around the validation.