DAO without Factory?

[tsagovic]

Hi guys,
I have a small question. I understand that DAOFactory is a nice thing, and it makes sure the right DAOImpl is returned according to your configuration. But do you really need to ALWAYS check your configuration/deployement file to return the right implementation? It is likely that you will be returning always the same thing, since these DATA sources don't change "everyday", and they could as well be HARd coded, or checked with something like a precompiler that will make sure your code is compiled with the right data code, and contains only that one.
Any thoughts? Would you make a DAO factory even if you don't anticipate to have dif. sources of the same data?
- BTW I have another question if you permit :), when would your factory return a new instance of the DAO each time it's getDAO is called, or rather have a thread safe singeleton DAO implementation?

Thank you for your time.

[spiritualmechanic]

I'd avoid a singleton DAO. You will have to synchronize things, which will slow you down if thread A is already in your singleton.

In general, avoid dealing with your own threads inside of the container. The whole point of J2EE is to let the container-developers figure it out for you.

I personally have used DAOFactory, and not used DAOFactory. If you're really doing some nutty stuff like changing which implementation you want to use on the fly (i.e., changing the value in a file, that is being read-in on a regular basis), you'd prefer writing a little MBean to do that. It'll be cached in memory and can be changed.

But most things don't need to be that dynamic. I definitely wouldn't make a DAOImpl too dynamic. Are you going to switch our databases on the fly? Just curious why you might want to replace DAOImpl.

There *is* a way in JBoss to have your interfaces not change, and change the implementation. Break the two into separate jars. If your implementation changes, just copy over the impl.jar. JBoss will pick it up without blowing away the objects that reference the interfaces.

Steve