Hi Aaron, I use controllers to do two things - request specific wiring that doesn't fit into the application.cfc onRequestStart() and onRequestEnd() methods and orchestration.
Simple example of first - put all form and url fields into a single scope to avoid conditional checking for variables that could be in either scope. Second is where controller shines for me. Often a request requires more than one call to the Model. Add item to cart could require Cart.AddItem(), Cart.UpdateTotals() and Cart.Get() (this isn't how I'd do it, just a quick example) to save the item, update cart totals and then get the updated cart for displaying in the selected view. Sometimes you want conditional steps that are not the service layers responsibility. If FormReturning, save. If valid, do this, if invalid, do that. Often you want to use business logic to decide what screen to display based on whether the form was valid. There is a place for cflocations, but also a place for being able to allow the controller to decide what screen to serve up based on business rules and request based information. The way we break it out is as follows: - Index.cfm is a generic controller handling all of the plumbing and we use URL rewriting and/or stub pages to end up there without the end user realizing this is a CF app (they go to history/about_us.html). - We have a set of features which are a publically accessible (under wwwroot) set of common things (newsletter, cart, product_catalog, etc.) which have methods for common functions (add to cart, view page, edit user, etc.). We also have some auto generated scafolding so you can always go to /user/edit.html and get default edit form assuming you have appropriate permissions in one of your security roles. The features are HTML agnostic and all return the same structure of information which can be consumed by the index.cfm, by flash remoting or by other appropriately authenticated services. - We have a set of services (here is where we are probably too procedural) which provide an interface to each entity - UserService.cfc, PageService.cfc, ProductService.cfc, etc. We put the core algorithms into a base class (e.g. BaseService.cfc and BaseDAO.cfc), parameterize and inherit from those with auto generated entity specific services (UserService.cfc, etc.) and then inherit from those with one time generated services which allow programmers to add custom code without losing it when the generator re-runs a la Reactor (CF ORM) and IronSpeed (.NET App Gen). - The services then let the DAO do the work for single record database interactions, a Gateway do the work for n-record database interactions and hook into Transform, Validate and Calculate services which also have base, entity and customizable entity versions and make up the core of our model. Just one example from a bit of a n00b to OOP. I've got a feeling others have better OO approaches. Hopefully they'll post them!!! Best Wishes, Peter -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Aaron Roberson Sent: Friday, June 09, 2006 2:40 PM To: CFCDev@cfczone.org Subject: Re: [CFCDev] Do I Really Need A Controller? 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 > > 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
