Custom Object Persistance (non-EJB)

Question

Hello friends.
Could you please give examples, or links to resources, on implementing object persistance where database is the store. EJB is not considered.
It would be great if you could share your experience.
So far I found out two desing patterns for implementing object persistance, that can be found on www.javaworld.com (under Persistance).
The idea expressed in the articles is that every Business Object has a corresponding Data Access Object, that handles all persistance tasks (namely writing, reading from database).
Has anyone implemented it? What are the alternatives?
Hope to hear everyone.

Answer 1

It seems that managing connection is a difficult
issue. Don't you think that factory has to accomplish
connection management, and DAOs have to have a
reference to factory, and call factory's
getConnection() and closeConnection() methods, and
factory will either open and close them, or return
them to pool.You've got a point. Managing connections in a non-EJB environment is the difficult issue. (With EJBs and DataSources this is piece of cake.)
When performance is not the issue, opening and closing a new connection for each db-operation should suffice. But when performance is the issue, things get a little more complex.
A naive way of increasing performance is to have DAOs cache connection objects. The only problem with this is that you would then require one database connection for one DAO. For some applications this would not be a problem, but as a generic solution this is really, really bad.
As for letting the DAOFactory handle connections I am not convinced. I would rather design and implement a separate connection pool (or find an open source / commercial one) than complicate my factories. After all, as the class name states, a UserDAOFactory is a user data access object factory, not a connection pool or a connection manager. Low coupling, high cohesion, eh? ;)
One way of implementing a connection pool I thought of is to write a ConnectionPool class and a PoolableConnection class (or something like that) that implements java.sql.Connection and acts as a wrapper for the real connection. Closing one of these connection would not actually close the connection, but would just return it to the pool.
What is cool about this approach is that you do not have to have your clients call some weird getConnectionFromPool() and returnConnectionToPool(...) methods, they would simply call ConnectionPool.getConnection() and when they are done with the connection they close it, just like a normal java.sql.Connection.
I am oversimplyfying things, of course. But in principle this is precisely what is done in J2EE, just use a "DataSource" for a "ConnectionPool".
Writing code for getting and closing connections in every dao seems a
bit of overhead.It definetely is. With EJBs I used an abstract DAO class to implement connection retrieval (and to hide JNDI-code and cache DataSources) and had all my DAOs extended this class.
Also, from your experience, you never used the generic
CRUD methods? It seems that all your daos have
specific methods, such as loadByUsername.
The article in javaworld get away from this by using
complicating mapping techniques. Have you ever used
generic CRUD, or you found it usefull to have specific
methods?Yep, I have never done anything with CRUD. And all this generic framework stuff and mapping things seems a bit complicated. Perhaps I will have a closer look.