The service objects are part of what you would call your Domain or Model The idea is your controller (cfm or cfc) asks the service for something ie a User or tells the service to do something ie save(User) The service is 'thin' and delegates to other objects to do most of the work ie the service's saveUser() method will use UserDAO's save() method Your DAO (data layer) talks to the db I also do things in the services like sending error notification emails when things go wrong in the lower layer objects. I wire a NotificationService into the services and use this to send the emails. As the services may require several objects to do bits of work it then makes sense to use a factory to handle all the dependencies, again you are encapsulating object creation.
The idea is that you are encapsulating each layer. ie your controllers have no idea about the DAO's, your services have no idea what db your using etc. Martin Fowler discusses the various layers and patterns in his book 'Patterns Of Enterprise Application Architecture' http://www.amazon.co.uk/Enterprise-Application-Architecture-Addison-Wesley-signature/dp/0321127420 ----- Original Message ---- From: Dan O'Keefe <[EMAIL PROTECTED]> To: [email protected] Sent: Friday, September 26, 2008 3:06:35 PM Subject: [CFCDEV] Re: CF, DAOs, CRUD and OO Thanks Alan, So is the customerService Object the domain object or do I need to add another layer? Dan On Fri, Sep 26, 2008 at 9:13 AM, Alan Livie <[EMAIL PROTECTED]> wrote: > 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 > > > > > -- -------------- Dan O'Keefe --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
