Announcement Announcement Module
Collapse
No announcement yet.
Exception handling (Dao or Service ?) Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Exception handling (Dao or Service ?)

    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 :
    Code:
    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 :
    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);
    }
    }

  • #2
    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.

    Comment


    • #3
      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...) :

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

      Comment


      • #4
        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/
        Last edited by karldmoore; Aug 30th, 2007, 06:13 AM.

        Comment


        • #5
          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

          Comment


          • #6
            Aren't you using this?

            Comment


            • #7
              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, ...).

              Comment


              • #8
                Originally posted by gonzalad View Post
                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.
                Last edited by karldmoore; Aug 30th, 2007, 06:13 AM.

                Comment


                • #9
                  Thank you very much for your appreciated help.

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

                  Comment


                  • #10
                    Originally posted by gonzalad View Post
                    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.
                    Last edited by karldmoore; Aug 30th, 2007, 06:12 AM.

                    Comment


                    • #11
                      I agree with your first approach of originating the exception in the service. IMHO, DAO's should be as dumb as possible, and only throw exceptions that are related to either a bad argument (IllegalArgumentException) or thier *specific* implementation. i.e. SqlExceptions if using straight sql, etc. The problem with throwing your checked exception from the dao, is that it's specific to a domain concern, someone is trying to save an existing user, and you want to catch the exception and recover. If this domain concern is left to the dao, someone wanting to add a new dao implementation also has to worry about whatever domain concerns the dao is supposed to provide PLUS it's actual data access requirements.

                      I view the actual service as the Repository, it's implementing the Domain concerns and calling DAOs to defer the actual data access.

                      Comment


                      • #12
                        Originally posted by lucasward View Post
                        If this domain concern is left to the dao, someone wanting to add a new dao implementation also has to worry about whatever domain concerns the dao is supposed to provide PLUS it's actual data access requirements.
                        I would agree, that's actually a better way of looking at it and explaining it .
                        Last edited by karldmoore; Aug 30th, 2007, 06:12 AM.

                        Comment


                        • #13
                          Thank you - really. I'm now sure to have a consistent approach for my exception handling.

                          Moreover, I can now connect the DDD Repository principle with the traditional layers (don't know why I was so sure in my mind Repository = Dao).

                          Comment


                          • #14
                            http://tutorials.jenkov.com/java-exc...-wrapping.html

                            Comment

                            Working...
                            X