Board index » jbuilder » Composite POJOs and database persistence

Composite POJOs and database persistence


2005-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
 
 

Re:Composite POJOs and database persistence

In <4245a61a$ XXXX@XXXXX.COM >Scott wrote:
Quote
Any feedback?
I use DAO a lot and I tend toward a rather pratical simple approach.
I don't break up DAO based on individual objects, but instead based on
"modules" that would operationally exist in my applicatons.. For
example I have an Account DAO that handles all issues related to persons,
permissions, groups..etc... Any composite group of objects that would
interact directly with or be part of and "account" is found in that DAO.
Then for example if you have a Project DAO and that project accesses or
links to accounts. That access "as it relates to the Project" is found
in the project DAO not the account DAO.
John...
--
=============================================
TeamB are volunteer helpers. Please DO NOT REPLY VIA EMAIL!
Post all questions and replies to this newsgroup ONLY
For papers on DataExpress, Applets, JSP, and Web Development go to:
www.microps.com/mps/paperFAQ.html
====================================================
 

Re:Composite POJOs and database persistence

John,
Thanks for your post.
Do you usually go with BizObj.save(DAO) or DAO.save(BizObj)?
Let's say you were doing an address book. getAddresses(filter),
getStates(), getCountries() would all be handy.
Would you make those objects in the DAO and have clients call it directly or
create an AddressBook() object with a DAO reference? The AB would probably
have a few extra bits of info like AB's owner...
Thanks
Scott
"John B. Moore (TeamB)" < XXXX@XXXXX.COM >wrote in message
Quote
In <4245a61a$ XXXX@XXXXX.COM >Scott wrote:

>Any feedback?

I use DAO a lot and I tend toward a rather pratical simple approach.
I don't break up DAO based on individual objects, but instead based on
"modules" that would operationally exist in my applicatons.. For
example I have an Account DAO that handles all issues related to persons,
permissions, groups..etc... Any composite group of objects that would
interact directly with or be part of and "account" is found in that DAO.
Then for example if you have a Project DAO and that project accesses or
links to accounts. That access "as it relates to the Project" is found
in the project DAO not the account DAO.


John...

--
=============================================
TeamB are volunteer helpers. Please DO NOT REPLY VIA EMAIL!
Post all questions and replies to this newsgroup ONLY
For papers on DataExpress, Applets, JSP, and Web Development go to:
www.microps.com/mps/paperFAQ.html
====================================================
 

{smallsort}

Re:Composite POJOs and database persistence

In <424c0c52$ XXXX@XXXXX.COM >Scott wrote:
Quote
John,

Thanks for your post.

Do you usually go with BizObj.save(DAO) or DAO.save(BizObj)?
Generally partition it so that the DAO ONLY contains the SQL code. Any
other database operation that is generic (i.e. not database specific) is
in the next layer(s) up..
Quote

Let's say you were doing an address book. getAddresses(filter),
getStates(), getCountries() would all be handy.

Would you make those objects in the DAO and have clients call it
directly or create an AddressBook() object with a DAO reference? The
AB would probably have a few extra bits of info like AB's owner...
Currently I create a layer above the DAO that is call the
"XXXXXDatabaseBean" (i.e. CartDatabaseBean, AccountDatabaseBean..etc..)
In this layer I put the generic tasks like saving, sorting, and
processing data. This is also the layer that manages the "connection"
and passes it down to the DAO as needed.
Hence the DAO only contains the SQL that can generally have unique
syntax that only works on that database.. The application only makes
call through the DatabaseBean NEVER directly to the DAO.. Though many
of the calls can just be a straight "pass thru" call..
John..
--
=============================================
TeamB are volunteer helpers. Please DO NOT REPLY VIA EMAIL!
Post all questions and replies to this newsgroup ONLY
For papers on DataExpress, Applets, JSP, and Web Development go to:
www.microps.com/mps/paperFAQ.html
====================================================