Re: [CFCDev] Calendar, Events, and CRUD

[Nando]

Maybe someone else can answer it better. Part of the problem seems to be that OO terminology means different things in different circles.  But i've come to understood 2 things from listening in to all these conversations over the past years. 1) the controllers / listeners in MII or MG should ideally be loosely coupled to your model. You should be able to pull your model out and implement it elsewhere fairly easily. 2) a service layer can help a lot where you need to get objects to work together. it's a means to coodinate and group small units of functionality together into a whole thing. a service also provides functionality for the app as a whole. in my mind, using the analogy of working with people, the boss (controller/listener) should direct teams and individuals. Sometime you need a team (a service) to get something done, or an individual to interface with many people (another form of a service) - and sometimes you need just an individual to do the job independently. But the boss/controller should only direct the teams, not participate in the work of a team/service. Does that make any sense? That's how i understand the differentiation at this point. Jeff Chastain 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: CFCDev@cfczone.org Subject: Re: [CFCDev] Calendar, Events, and CRUD Learning 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 cfcdev@cfczone.org 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/cfcdev@cfczone.org ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org -- Aria Media Sagl CP 234 6934 Bioggio Switzerland www.aria-media.com