Hi
Jeff,
Personally, I look at the controller as a facade to the business model,
simplifying the steps required to perform useful page
actions.
Lets
say you have a cart page which has an add to cart method. I'd create a cart
controller/facade (cart.cfc). I'd also make it somewhere under your www
directory to allow for flash remoting or exposing as a web service if
appropriate. I'd then add methods like addtoCart(), updateCart(), viewCart() -
basically any of the actions that a link or form could
request.
I
would then make each of the controller methods a very simple set of calls to
either the objects (like a persistent cart) or to the object services (such as a
CartService). My rule is that if functionality is inherent to the entity, it
should be in either the object or the object service. Most transformations and
validations fall into this category as does the ability to persist the entity
(which should be abstracted using a DAO underlying the service layer and the
object if you are ever going to consider supporting more than one persistence
mechanism). If the functionality is specific to the application/page view then
it should be put in the controller.
When
we generate applications, controllers just set properties and then orchestrate
the calling of business model methods (either in the object classes or the
object service classes). They can include business rules that relate to the page
view/application, but we keep all of the transformations, validations and
security rules that are inherent in the business entities either in the service
classes or in the object classes themselves.
I
think of a service layer as an orchestration layer, just setting the bits and
pieces of properties and calling the business model classes to do all of the
actual work. I would argue that you should be able to drop in a completely
different set of controllers to do different things with the same objects
without losing any of the underlying functionality of the business entities. I
look at the business entities as building blocks. The controller is a set of
rules telling you what order to use the blocks in to achieve well defined page
specific outcomes.
Best
Wishes,
Peter
Peter
---------------------------------------------------------------Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeff Chastain
Sent: Tuesday, April 25, 2006 1:58 PM
To: CFCDev@cfczone.org
Subject: RE: [CFCDev] Calendar, Events, and CRUDOkay, 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.
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.
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
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
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
