I would suggest ONE service object. I think service layer should be grouped by functionality ie CustomerService would handle all the customer, customer address and user tasks.
----- Original Message ---- From: Dan O'Keefe <[EMAIL PROTECTED]> To: [email protected] Sent: Friday, September 26, 2008 1:20:53 PM Subject: [CFCDEV] Re: CF, DAOs, CRUD and OO > A DAO is something that lets you persist an *object*. It really shouldn't > matter if that "maps" to one database table or 10 database tables. If it > takes 10 tables to properly persist your domain object, then the DAO should > deal with 10 tables. While it is *common* for an object to map to a single > table, this is definitely not mandatory. DAOs exist to "translate" a domain > object into some kind of persistence system. The key is to think from the > object model back, not from the database forward. Brian, That is my problem and something I am looking to overcome, which is thinking from the database forward. I think the ORM's have tended to mold me that way. So if I could give an example and ask if anyone would like to crtique it: For an app using Transfer, I have customer, customerAddress, customerUser tables (customers with multiple locations and multiple users per customer to log into my system). Transfer will give me seperate objects for each of those tables. I will use a service layer object to communicate with each of those table objects. I am not sure if I would have a separate service object for each table or one for all 3 - and then I would have my user bean in my object model. Make sense? Thanks much, Dan --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "CFCDev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cfcdev?hl=en -~----------~----~----~----~------~----~------~--~---
