what things to write in userDAO class in java spring hibernate

I have domain class User with properties and getters

Then i have userService class which contan all functions like

addUser DeleteUser

public void register(User person) {
      logger开发者_C百科.debug("Adding new Registration");
      Session session = sessionFactory.getCurrentSession();
      session.save(person);
     }

I am using hibernate.

My system is running fine . but i am confused where does UserDAO stands in my case. Do i need it or what things i need to write in there

---

There's nothing that forces you to have a DAO layer.

UI <-> Service <-> DAO <-> persistence

The code in your session layer is what normally goes into a DAO layer. I.e. small (almost atomic) operations such as store, delete, etc.

The service layer is for isolating business logic that would be awkward in a simple storage layer. For instance, if you want to operate on multiple Person instances at a time, or some very specific business logic before saving the object. Another common use with RDBM is to have transaction management in the service layer, coordinating possibly multiple DAO requests into transactions.

In many simple applications the service layer is somewhat pointless. It just proxies operations, like your above, from the UI to the DAO - no logic added. In these cases I would personally not necessarily create the DAO layer, keep the storage in the service, but refactor it out the very minute it grows beyond being just a simple persistence layer.

Another aspect is unit testing. A simple DAO layer can easily be mocked away which is an argument for keeping business logic and persistence strictly separate.

---

As already pointed out here, it's not necessary that you need a DAO layer at all. If your service layer doesn't contain much logic, you might find it acceptable to put DB/Hibernate logic there. What you don't want is to put your DAO logic in the UI-layer as it makes unit testing harder and messier.

Another solution is to check out a library that makes writing the DAO layer easier. Hades is such a library which in many cases gives you all necessary dao methods for free. With Hades, your DAO-code would look like this:

public interface UserDao extends GenericDao<User, Long> {
}

You then get methods such as persist, find (also with paging), count, delete, etc.

---

I went with this approach at my last job (particularly the one in your own answer, Aleksander) and I found that the DAO really got bogged down with the logic and relationships that needed to be in the User itself. I agree with Martin, you really don't need a DAO. If anything, use a generic type-safe SessionFactory wrapper.

  public class SessionFactoryWrapper{

       private SessionFactory sessionFactory;

       public <T extends ObjectWithID> T load(long id, Class<T> clazz){
             return (T) sessionFactory.getCurrentSession().load(clazz, id);
       }

       //... etc...
  }

This forces you to interact with your session abstractly, and deal with model-level code in your domain, which tends to keep code cleaner.

---

DAOs generally contain data persistence operations. With ORDBMS, they are mainly CRUD(Create, Read, Update, Delete) operations. DAO stands for Data Access Object. Take a look at generic dao

Even though your service layer doesn't contain much business logic, it is good idea to separate data access layer from service layer. It is usual dilemma of why do I need one more layer if my code is simple enough to fit in one layer. Indirection and Refactoring

Basically if you keep tasks and responsibilities separate, it helps in making code more adaptable to change. I hope that answers both the questions (what and why)