I also wrestled with these design and patterns. In the end I dumped the business object (well I dumped the DTO's actually) because copying between them was very tedious - OJB handles that for you throught the mappings (so why do it again i thought). I don't see anything wrong with this approach as long as you hide OJB from the rest of your layers (after all they can't see your business objects can they?).
The benefit of OJB is that it is transparent so your Bo's/DTO'/Vo's (whatever you've called them! ;-) are just pojo's Once i took this approach my development speed increased and I stopped fighting the architecture. I Still however do translations between the view layer and the business delegate layer and use DTO's to transfer the from http requests (after they've been validated and typed cast etc) to the business layer and back again. HTH Jin ----- Original Message ----- From: "Shane Mingins" <[EMAIL PROTECTED]> To: "'OJB Users List '" <[EMAIL PROTECTED]> Sent: Tuesday, June 24, 2003 9:06 AM Subject: How Do Others Use OJB With DTO's and Business Objects? > Hi All > > I just wondered how others are implementing their persistence layers using > OJB? > > This is what I am looking at doing at the moment but I am wondering whether > or not it makes sense? > > I have a Data Access Class (DAO) that provides access to a Data Transfer > Object (DTO) like: > > CustomerDAO with methods insert(CustomerDTO), update(CustomerDTO), > getByName(String) etc. > > So the way I am viewing it is, any returned object from the CustomerDAO > would be a DTO. And anything passed to it would be a DTO. > > Within the CustomerDAO, any interaction with OJB (FYI using ODMG) is done > via BusinessObjects. > > So a getByName(String) will query the database using OJB, return a > CustomerBusinessObject to the CustomerDAO which will populate a CustomerDTO > and return it to caller. > > An insert with provide a CustomerDTO to the CustomerDAO which will inturn > create a CustomerBusinessObject and persist it. > > An update will provide a CustomerDTO to the CustomerDAO which will inturn > get the existing CustomerBusinessObject, update it from the CustomerDTO and > persist the changes. > > Does this sound reasonable? > > It just seems like an awful lot of "copying" that becomes quite difficult > when an Object contains a collection of other Objects. > > I have been using the BeanUtils.copyProperties() method to do my copying but > when it come to a collection I have to iterate through it otherwise the > objects within the collection of the new DTO object [like returned in > getByName()] would contain references to BusinessObjects and not DTO's. > > Any thoughts or comments? > > Cheers > Shane > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
