Re: Database helper class with PreparedStatements

teser3@hotmail.com wrote:


Bear in mind that the code I presented is itself untested. Assuming I made no
errors, it still is not the only way to go about things.

The decomposition of the methods was designed to allow PreparedStatement reuse
where possible. It also allows sharing a Connection between helper classes in
some putative expansion of the concept. That's why all the overloads.

If you parametrize the class on the entity type rather than just City, you can
come up with a pretty decent Data Access superclass. You still need to
override methods in child classes that are smart about
object<->PreparedStatement and object<->ResultSet specifics.

When I've done this I wind up with a fairly complex framework, one really big
AbstractDataAccessor class and a lot of very easy, quick child classes that
correspond to each entity. Once the framework is in place it's easy to adapt
to new entities.

That said, the new Java Persistence API (JPA) (see also Hibernate) looks to be
a much more robust, portable way to handle object persistence to RDBMSes.

--
Lew