What the original poster is getting at is that if you need to do additional logic (e.g. send an email) then that is Controller like action. What happens if one day someone says, "hey, in addition to sending an email, write a row to a log file, or do this or do that" then now you have to go modify your view file to handle this additional logic. This doesnt belong in the view. Nor does it belong in the service. The service layer should that sends an email should only worry about sending an email, not doing anything else. This is where "separation of concerns" comes in. Your Controller ties this all together. The Controller fires off a call to your email service to send an email, it then fires off a call to your Logger service to log a message, it then fires off a call to a some DAO object to write a row to the DB it then puts a message in Session scope and then it finally cflocates you to some other page...etc... Thats the traffic cop! The Controller knows that it needs to perform all of these actions so it glues the various services required to do this together.

/cody

Dustin Tinney wrote:
Do you send your user a "verify" email or a "thanks for subscribing email"?

On 6/9/06, Aaron Roberson <[EMAIL PROTECTED]> wrote:
I have an email subscription form on my website that visitors can fill
out and subscribe to our newsletter. I have created a
subscriberBean.cfc with getters/setters and an email validation
method, a subscriberDAO.cfc with CRUD methods, and a service that
creates a DAO object and a gateway object and passes arguments to the
DAO and the gateway (this is all based on Matt Woodwards
CF.Objective() example and Peter Farrell's code examples from CFWeekly
1.10).

It seems to me like the view would interact with the service, which
would perform my CRUD operations and return my the query results from
my gateway. If so, what do I need a controller for? I've heard that
controllers act as traffic cops, but I'm not sure what that means. If
my view is validating form field entries, and my model is validating
form field entries, and my view is getting everything it needs from
the service layer, what do I need a "traffic cop" for?

Thanks for your feedback and suggestions!

-Aaron

On 6/9/06, Dustin Tinney <[EMAIL PROTECTED]> wrote:
> Yes would be the answer to your question about needing a Controller.
> However with out knowing what your doing a little more It's hard to
> give direct examples of WHY you need it.
>
> On 6/9/06, Aaron Roberson <[EMAIL PROTECTED]> wrote:
> > I have been plunging head first in to OOP (into a wall, I should
> > say...) and I am trying to put all the pieces together so that I can
> > begin implementation.
> >
> > Anyways, I am wondering if I need a controller layer in my design
> > pattern? I really don't like the idea of using a configuration file
> > (xml or index.cfm) and wiring everything to it like a fusebox, so I am > > staying away from frameworks. I have been learning about seperating my
> > business model into beans, DAO's, gateways and services and I think I
> > like the abstraction that offers. However, it seems to me like my
> > views can interact directly with the service, making a controller
> > layer unneccesary. Is that correct, or am I lost again?
> >
> > P.S. I don't entirely understand what all a service does, so I do have
> > some questions about the service layer, but I will start a seperate
> > thread for that. I would have some questions about the facade layer,
> > but I don't have a clue how to use that so I don't even know where to
> > begin with the questions regarding that.
> >
> > Thanks,
> > Aaron
> >
> >
> > ----------------------------------------------------------
> > 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]


Reply via email to