Singleton or static methods for DAO?


General J2EE: Singleton or static methods for DAO?

  1. Singleton or static methods for DAO? (9 messages)

    Which is the preferred way of creating a DAO which has no state...Singleton or static methods for DAO? and why?

    Threaded Messages (9)

  2. Singleton or static methods for DAO?[ Go to top ]

    It depends on how sophisticated you want to be.

    If you put your DAO logic in a static method, then that logic is fixed, and cannot be changed. Static methods cannot be overridden.

    If you put your DAO logic in instance methods of a singleton, you have the option of overriding those methods. You could, for example, use a configuration value to replace your real DAO with a mock object that fakes DAO operations for testing purposes.

    Note that if you screw it up (and use static methods) you can still fix things by having your static methods delegate to a singleton.
  3. Not static[ Go to top ]

    Try and avoid the use of statics as much as possible.

    Instead, pass an instance of the DAO to whatever class will need to use it.

    Better still, make the DAO implement an interface. That makes testing a heck of a lot easier.


  4. I think it depends,Singleton could cause problem depending on the logic, if there are multiple clients accessing you might have to synchroize the part of the code... and which could be a bottleneck...and static method has a problem as mentioned during inheritance...
    I would say session Facade would be better option, where you can use stateless Session beans (EJB) and will in turn call your DAO...which is not a singleton...and also your session bean can be composed of DAO...

    Hope that helps..

    Venkatesh Rajmendram
  5. How about if the DAO doesn't have any state.
  6. Well lets say you have a DAO which is a singleton, and lets say it has a method getResultset(String someString) which returns a RS after passing some parameters from a screen, Now if you have multiple clients accessing this method at same time...the result set might not be client expected...hope you got my point...It would be same in case of insert and update...Well I am not sure when you say Dao does not have state...

    hope that helps...

    - Venkatesh Rajmendram
  7. Singleton or static methods for DAO?[ Go to top ]


    If your DAO does not have any state (no instance variables) it is perfectly safe to make it into a singleton. No instance variables means no chance for thread-conflict.

    You do need to be careful how you initialize the singleton, though. Some like this should be safe:

    public class ExampleDAO {
      private static final ExampleDAO SINGLETON = init();

      private static ExampleDAO init() {
        // Init the DAO ...

      public ExampleDAO getInstance() {
        return SINGLETON;

    The singleton is stored in a static final constant, and is therefore thread-safe.

    The main advantage of this approach is that you can modify the logic in the init() method to create a MockDAO instead of a real DAO, based on some configuration value, which simplifies your unit testing. Alternately, you can have a switch that will create DAO customized for different databases, or ones that work inside/outside the container (using the DriverManager vs. a DataSource), and so forth.
  8. Singleton or static methods for DAO?[ Go to top ]

    Hi Bruce,

    I would write the DAO as an interface and the implementation as a simple java class (neither a singleton nor having static methods). In order to avoid creating multiple instances of the DAO classes again and again, i can cache the instance created inside the DAOFactory class(the factory class that generates the DAO). In this way i can improve performance reusing the same DAO instance again and again. Only thing one needs to make sure that in that case, i shouldn't have Connection (in case of JDBC implementation) or Session (in case of Hibernate) as class level variables. I have used this approach in my projects successfully.

    Hope this helps,
  9. Singleton or static methods for DAO?[ Go to top ]

    Thanks all.

    In response to Sumanta reply:

    This, your approach is good when you have multi objects which can implement the DAO. In emy xperience I don't have different databases or ever a generic enough DAO that makes this model work. Typically I have.


    SomeDAO (concrete class)
    - doesn't have state, so I make it a singleton.

    SomeEJB uses SomeDAO

    Or (not that often)


    I have a generic enough DAO

    SomeDAO (interface)

    Two concrete classes implement it. Some1DAO and Some2DAO

    then I would have a Factory to obtain instances of these

    Long story short, example 1 is the route more often.
  10. Singleton or static methods for DAO?[ Go to top ]

    Hi Sumanta,

        It is interesting the way you implement, does it going to give any benefit over singleton when u r calling DAO from session facade? I am interested to how we can get the benefit of singleton in multithread environment.