DAO - Static methods vs multiple class instantiations
Hello
The Data Access Object pattern (DAO) is a well known pattern that is used with domain models, even when using Entity Beans. However, normally, the pattern involves instantiating extra objects, rather than using static methods.
So for example, it is not unusual to have an entity bean and 2 additional objects to implement the DAO.
1)Why not use a class with static methods that implement the JDBC calls? Surely, in a multi-user environment, this would be advantageous for performance and scale? And as far as I can tell, the DAO generally does not encapsulate any data as such.
2) Equally well, the Entity bean could sure pass a reference to itself (via "this") to the static methods of the Data Access CLass. The DAO class could then populate the entity bean propoerties directly, rather than having to create a plain old java object that essentially is identical to the entity bean, and then having the entity bean copy this data to itself.
I do realise that the Entity Bean spec prevents an entity bean from returning a reference to itself via "this", but as I described it , I do not se a problem (and it does work!)
Can someone set me straight please?
Confused
Paddy
[1232 byte] By [
jcc123a] at [2007-9-29 15:45:29]
Consider the case where your DAO accesses an XML file. If you use static methods, then you have to re-load and reparse the XML file for every method call.
You could create a private static variable and assign it to the root of the XML document, then each static method could work with the root variable instead of reparsing everytime.
However, using the static private root variable, raises other issues. For example, you cannot re-use that DAO class for accessing several different XML files. For example, if you want to have two DAO objects of the same class, accessing two different XML files you will have problems doing so.
However, you are right that the static-ness provides improved perfromance, I think it depends on how you want to use your DAO object.
Hope this helps.
Bill
> I do realise that the Entity Bean spec prevents an
> entity bean from returning a reference to itself via
> "this", but as I described it , I do not se a problem
> (and it does work!)
Just because it works for you and in your situation/server does not mean it works universally. As you said yourself, it is a violation of the specification and you just broke the container's ability to manage instances and threads.
As for mixing EntityBeans and DAOs - you shouldn't. Using a DAO for accessing (locally) an EntityBean that is fronting for the same table(s) as "straight" JDBC or JDO, you just broke the ability for the container to accurately manage your EntityBean cache.
Two questions, two breaks...
As for the POJOs, with the advent of Local interfaces for, say, StatelessSessionBean->EntityBean interactions, the only time you "need" them is to use JavaBeans/DataTransferObjects/DataObjects/ValueObjects as transfer mechanisms to the SLSB clients. You don't need to use them that much within the container...
