This does make a lot of sense. It makes my simple
little app a lot more complex, but it does make sense. Has anybody put
together a "best practices" sample app showing all of the different layers and
types of objects (assuming such is possible)?
Thanks and off to tinker again.
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Cody Caughlan
Sent: Tuesday, April 25, 2006 2:02 PM
To: [email protected]
Subject: RE: [CFCDev] Calendar, Events, and CRUD
These are my thoughts on the matter:
- A MachII listener is the bridge between the data (service
layer) and the web views. The listener knows about URL, Form, elements, etc. It
knows that a certain view expects a query to be set it in so it can loop over it
and display it.
- A Service is deals with the business logic. Depending on
how you break it out (you can go even deeper) a Service object talks directly to
the DB and when a form needs a list of people, via the listener it asks for this
query by asking a Service layer object. This object knows that to get a query of
people it has to do joins here and there, etc. So the listener is dumb in a
sense, it needs a query, it asks the Service object for it and gets it back,
inserts the query in event scope (or uses the resultArg attribute) to do it
automatically. The Service layer should have no references to Request, URL,
FORM, scope, etc. It might talk to Session scope via a
facade.
Ideall the Service layer is thin. So in the above case when
it needs a list of people, it really talks to a "PersonManager" or a
"PersonGateway", depending on your naming conventions and then PersonGateway has
a method "getAll()" or something like that.
So it works like this (extreme
psuedo-code):
component: MachII PersonListener:
function getPeople() {
PersonService = CreateObject('PersonService');
PersonService = CreateObject('PersonService');
return
PersonService.getAll();
}
component:
PersonService
function getAll()
{
'PersonGateway'=
CreateObject('PersonGateway');
return PersonGateway.getAll();
}
component:
PersonGateway
function getAll()
{
<cfquery
name="qryPeople">....</cfquery>
return qryPeople;
}
Basically the
Service is a thin layer which makes calls out to your thicker layers, the DB
persistence layer (often called the aggregate access and Data Access layer).
When the app is broken up like this, you can re-use all of the little pieces.
When a component needs arguments, (e.g. a sort by column) *do not* pass along
the Event object (which *does* contain this info, e.g. it has a GET parameter
called "orderBy")) because if you were to do this, you would then tie your
Service layer to MachII, that is your Service object would know that it can
accept an object of type MachII.framework.Event, which is *BAD*. Your listener
should make a struct of its own, extract the orderBy column from the Event
object and pass this generic struct to your Service object, which in turn passes
it down to the PersonGateway. Keep each layer independent. If you didnt, and
later you wanted to move to FuseBox or some other framework, you couldnt easily
do so because deep in the bowels of your Service or Gateway object would be a
reference to a MachII Event object.
Hope this helps.
There are a many ways to skin the cat, but the above is generally how I approach
it.
/Cody
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Jeff Chastain
Sent: Tuesday, April 25, 2006 10:58 AM
To: [email protected]
Subject: RE: [CFCDev] Calendar, Events, and CRUD
Sent: Tuesday, April 25, 2006 10:58 AM
To: [email protected]
Subject: RE: [CFCDev] Calendar, Events, and CRUD
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 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 [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] ----------------------------------------------------------
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]
