Board index » jbuilder » Composite POJOs and database persistence
Scott
 JBuilder Developer |
Composite POJOs and database persistence2005-03-27 02:11:04 AM jbuilder14 I've been doing a lot of reading on patterns lately and wanted to use some of the principles in a current project. Let's say.... * 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. Any feedback? Thanks Scott |