I consider the listeners to be part of the controller, simply passing data between the config.xml and the Model (service cfcs, DAOs and Gateways). In some cases the service layer does the same as the listener, just passing on the arguments to the DAO or Gateway. In other cases, such as the one you described, my service cfc will do a bit more. Generally, my controller and service layer have functions with the same names.
One thing I like about the service layer is I can use CFCUnit to hit a function in a Service CFC for testing. I can also write a simple .cfm page, independent of Mach-II and its listeners, that invokes the Service CFC, calls functions that access either the DAO or gateway, and does a cfdump on any returned data.
Does that help any?
On 4/25/06, Jeff Chastain <[EMAIL PROTECTED]> wrote:
Okay, I have been digging to find more details on exactly what a service layer should contain and I am not coming up with much. If I am using a framework such as Mach-II, what is the difference between the controller and a service layer? How do you determine what functions go into the controller vs. the service layer? I have seen several articles mentioning that the service layer should be very thin, so are there any rules as to what should and should not be in a service layer? Maybe I just need a better definition.Thanks.
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Matt Williams
Sent: Tuesday, April 25, 2006 11:20 AM
To: [email protected]
Subject: Re: [CFCDev] Calendar, Events, and CRUDLearning from others, I started using a service layer that does the talking to the DAO. In your example you could have a CalendarEventService.cfc with a getCalendar function. This function would call the Read on the calendar DAO and then hit the event gateway.
I did something similar with some Cash stuff. One transaction can have multiple items. I get the one transaction object, then get the items. Here I actually have an object for each item and stick them into an array. That 'Array of Objects' is then put into the transaction object.
Make sense? And if you're not already using it, ColdSpring makes all the object creation in the Service cfc really easy and painless.
On 4/25/06, Jeff Chastain <[EMAIL PROTECTED]> wrote:I am playing with a simple little application and I am running into some questions on data access. I have a calendar object that along with other information, has one or more event objects associated with it. So, when I tell the calendar DAO to give me a calendar instance based upon a given id value, it goes to the database and pulls all of the details regarding that calendar. But, it gets to the point of needing to populate its event array and gets stuck. Does the calendar DAO know about an event gateway that can provide it with a list of events? This just sounds wrong, but I am not sure how else to do it.Any suggestions from the more experienced?Thanks.----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting ( www.cfxhosting.com).
An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com).An archive of the CFCDev list is available at www.mail-archive.com/[email protected] ----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting ( www.cfxhosting.com).
An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com).
An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
