Java design pattern question

[Terry]

Hello. I'm beginning to work with patterns and would really appreciate
some of the group's feedback regarding a problem I'm solving. I'm
looking for a way to abstract a persistence layer interface in a way
that would require little or no modification of the rest of the
application if the underlying storage medium were to change. Pretty
standard, no?

Currently, I've implemented the persistence layer as a package of three
interface files. The main data store interface holds all the usual
methods such as getBizObject(), removeBizObject( id ), saveBizObject(
bizObj ), etc. A second interface is a BizObject iterator, and the
third contains misc utilities. I've implemented a DB store by extending
these three interfaces, the idea being that when the data store medium
changes, we have only to extend the interface files again and the
application has no knowledge that its data is persisted in another
medium.

This works of course, but it doesn't strike me as a particularly elegant
solution.

My requirements are these:
- The application is currently a web app, but could be moved to SOAP or
EJB so I don't want to rely on a container.
- The number of classes comprising the persistence layer may change
- The underlying data store will change often.


What I'm after is this:
- I'd like for changes to the store medium be completely transparent and
unobstructive to the rest of the application code.
- I'd like to have implemented persistence "packages" (implementations
of the above mentioned interface files) be swappable - perhaps bundled
in a JAR file which is then placed in the app's classpath.
- Changing persistence "packages" should be configured outside the
application, such as in a properties file with no changes to application
code.

I think I'm close, but I'm still missing a few key pieces. For example,
how do I get an instance of one of the persistence classes? In the case
of the main data store, I'd want it to be a singleton so it doesn't
incur the overhead of setting up the connection each time I want to use
it, and I don't know what the class name will be ahead of time for
persistence "packages" I haven't written yet. Is this where the factory
pattern is useful? Can the factory get the appropriate class type from
the configuration file, instantiate a singleton and return it? Is there
another pattern well-suited to this situation?

I'm still pretty new to patterns and Java, so I'd really appreciate any
feedback you can offer.

Thanks!

Terry.

 

[Andy Fish]

Can the factory get the appropriate class type from
the configuration file, instantiate a singleton and return it? Is there
another pattern well-suited to this situation?

that's exactly what I would do. Though to be honest I wouldn't implement
that bit until you actually need to support different storage media (google
YAGNI)

I'm still pretty new to patterns and Java, so I'd really appreciate any
feedback you can offer.

don't get too hung up on patterns. concentrate on solving the business
problem. I'm not saying patterns aren't good but they aren't a religion.

Andy

 

[tom bender]

Personally I would separate persistance responsibilities and business
behaviour by having a separate set of manager interfaces, concrete
examples of which can be intantiated using a factory (via dynamic
instantiations) and which deal with persisting the business objects.
The business object classes can then remain unchanged regardless of
choice of persistance mechanism.

By mixing persistance and business you end up needing N*n
implemenentations (N is number of Business Objects, n is number of
persistance layer mechanisms). With the manager class approach you only
need N+n implementions.

This manager method also localises impact if you do choose a different
persistance mechanism.

Tom

 

[Chris]

Sounds like a good fit for an Abstract Factory pattern:

http://www.javapractices.com/Topic128.cjp

This should satisy your requirements of:

- keeping the actual persistence mechanism transparent to it's
client(s)

- ability to easily swap persistence mechanisms, possibly via some
sort of config file

How to package the various components is harder to answer without more
information, and (unfortunately) is often dependant on where it is
deployed (web-server, app-server, etc) - this is more of an art/magic
IMHO.

- sarge

 

[Terry]

Thanks for the feedback! It's encouraging to know I wasn't too far off.

- Terry.