Board index » jbuilder » Composite POJOs and database persistence
Composite POJOs and database persistence
2005-03-27 02:11:04 AM
I've been doing a lot of reading on patterns lately and wanted to use some
of the principles in a current project.
* I have a Person class. A Person can have one or more Addresses.
* I have a User class, which contains a Person class and adds stuff for
login, roles, etc.
* I have an Order class, which has Shipments, which each contain a Person,
an Address and a Shipper, etc.
Basic stuff I know.
What I'm uncertain of is the design of the database/persistence tier. The
Core J2EE Patterns book talks about the Data Access Object pattern (p 462)
for saving business objects. The example shows a the DAOFactory which
implements methods to create a CustomerDAO and an EmployeeDAO.
In the examples, these two objects have no relationship. So it seems
reasonable to separate the two. But the absence of any composite objects
leaves me a little unsure about a design approach:
* I can write one DAO for all classes with methods like updatePerson,
updateAddress, etc., and then composite objects can call all the methods
necessary to save themselves and their children. DAO's seem a bit like the
Bridge pattern (GoF) to me. And this seems like a Bridge-style
implementation, except instead of the drawing methods given as examples in
that book, I've got db methods. This doesn't seem like a crazy idea.
* I can write one DAO for each class, but DAO's for composite classes will
effectively be composite DAO's. In other words, UserDAO would contain a
PersonDAO just like User contains a Person. DAOFactory needs to know how to
build the composite DAOs and so needs to be a bit smart about how the
composite POJOs are constructed. Alternatively (or even in addition), each
DAO could get a reference to the factory that created it and construct
itself. Seems kind of neat and tidy.