DAO implementation questions

[manish ahuja]

Hi all,

I have some questions on going about DAO implementation.
We are using Hibernate O/R mapping as the persistence framework. So I have created one DAO per Hibernate object/database table combination which comprises the CRUD methods and extend from an AbstractDAO.
The service layer directly creates these DAO instances and uses for database related activities (reads/updates/inserts etc).

1) My question is should I have 1 interface each per DAO and the service layer should interact only with the interface. I am not using Spring for dependency injection. Nor do we have plans to change the implementation from Hibernate to some other OR mapping framework.
2) Should i create a DAOFactory where in I statically pre-initialize all the DAO's in the environment and in the service layer fetch the DAO's from this factory rather than creating DAO instances on the fly.
3) Should the methods inside the DAO (create/update/delete/find) be static methods.

Would appreciate if you can share your thoughts on the same.

Regards
Manish

[Jimmy Clark]

1) My question is should I have 1 interface each per DAO and the service layer should interact only with the interface. I am not using Spring for dependency injection. Nor do we have plans to change the implementation from Hibernate to some other OR mapping framework.

What are the benefits for this design? What are the disadvantages? If you have 20 DOA classes, will you then have 20 interface classes as well? Do you think the API of the DAO classes will change often?

2) Should i create a DAOFactory where in I statically pre-initialize all the DAO's in the environment and in the service layer fetch the DAO's from this factory rather than creating DAO instances on the fly.

I suggest having a factory class that creates the DAO objects for client objects. I would not attempt to "statically pre-initialize all the DAO's."
Client business objects should fetch the DAO's from this factory on the fly.

3) Should the methods inside the DAO (create/update/delete/find) be static methods.

Definitely not.
[ November 18, 2008: Message edited by: James Clark ]

[manish ahuja]

Thanks James.

-------------------------------------------------
quote:1) My question is should I have 1 interface each per DAO and the service layer should interact only with the interface. I am not using Spring for dependency injection. Nor do we have plans to change the implementation from Hibernate to some other OR mapping framework.

What are the benefits for this design? What are the disadvantages? If you have 20 DOA classes, will you then have 20 interface classes as well? Do you think the API of the DAO classes will change often?
-------------------------------------------------
No the API of the DAO classes will not change often. So i guess I don't need to go for an interface oriented design for this scenario.

-----------------------------------------------------
quote:2) Should i create a DAOFactory where in I statically pre-initialize all the DAO's in the environment and in the service layer fetch the DAO's from this factory rather than creating DAO instances on the fly.

I suggest having a factory class that creates the DAO objects for client objects. I would not attempt to "statically pre-initialize all the DAO's."
Client business objects should fetch the DAO's from this factory on the fly.
-----------------------------------------------------
But the DAO objects will still be static references inside the DAOFactory. Correct me if i am wrong here.

----------------------
quote:3) Should the methods inside the DAO (create/update/delete/find) be static methods.

Definitely not.
----------------------
Can you elaborate the reason for the same.

Thanks in Advance.

Manish

[Jimmy Clark]

Thanks.

There is no apparent reason to use "static" methods or store the DAO objects as static class variables. The DAO objects will belong to one or more collections. A factory object will be used to create the DAO objects.
[ November 19, 2008: Message edited by: James Clark ]

[Sebastian Oliver]

Hey Manish,

* Why do you need a DAO per table supporting CRUD operations ?

Let's think another approach.

* Aren't those common operations that apply to all Objects ?

Sure, so let's create the GenericDao interface with the CRUD methods.

* Hibernate should be used ?

Yes, so let's create the class HibernateDao, and let's implement the GenericDao interface created previously and so its methods.
We can add a method to exec named Queries.

* Why to call it DAO if it's not some entity domain specific, otherwise a framework component applicable to other projects !?

Right, so let's refactor both name, let GenericDao be named Repository and HibernateDao be named HibernateRepository. Sounds better since we got a repository of objects that support CRUD operations.

* OK, but now I need to create a DAO to retrieve an Entity given a certain criteria !

Well, for these cases let's create our entity domain specific DAO. Create the %EntityName%DAO, let it wrap the Repository instance and that's it.

You can plugin the Repository instance to any entity domain DAO you create on the way, being the Repository the framework/generic/reusable guy in charge of CRUD/SQL Queries operations and the DAOs the domain Data Access Objects that access to DB asking the Repository, and Casting and other stuff.