Agreed 100%. I mentioned that in passing, but if you're still getting up to speed with service layers and DAO's, throwing in AOP as well could be confusing.
I agree it is the ideal approach as this sounds like the text book "logging cross cutting concern" which is used as the example for AOP everywhere. I just pointed out that you could initially put the call to the logging object in your service methods and then refactor it into advice once you got a little more comfortable with OO and CS and all of the other joys of OOP in CF! Best Wishes, Peter On 12/21/06 9:15 PM, "Barry Beattie" <[EMAIL PROTECTED]> wrote: > considering the counter is a by-product of the getting of the record, > wouldn't this be a suitable candidate for AOP? (in this case > coldspring) > > I'm just throwing up the counter is much like a logging process and > the getting (and processing) of data might not need direct cluttering > with other concerns? > > just a thought > b > > > > On 12/22/06, Aaron Roberson <[EMAIL PROTECTED]> wrote: >> On 12/21/06, Peter Bell <[EMAIL PROTECTED]> wrote: >>> Hi Aaron, >>> >>> To take a slightly different tack: >>> Q1: >>> - You don't want to track this in view as responsibility of view is to >>> display state - not to change it (by recording an updated number of views) >>> - If you ever added an AJAX or Flex or web service front end, would you want >>> to keep track of number of those views as well? If so (which would make >>> sense for most use cases) you want to add this to your model - not your >>> (HTML specific) controller. >>> - As to where to put this in the controller, I'd put it into your service >>> objects (or managers if that is what you call them). Why? Well, some time >>> you might add caching so you don't always return to the db, so the >>> DAO/Gateway is probably the wrong place, but you always have to ask the >>> UserService to get a list of users or ProductService to get a list of >>> products, so add the code there. >> >> Thank you for filling in some more of the details. Because the counter >> would have to increment the value of a field in the db record, it >> seems odd to put this in the service layer however. What do you think >> about Sammy's suggestion of having two methods - one for views which >> increments the counter and one for edit forms which does not >> increment? >> >> As for Q2, I am going to have to take a look at Doug Hughes stuff and >> come back to it, I am at a complete loss not knowing anything about >> Facades. >> >> -Aaron >> >> >> You are subscribed to cfcdev. To unsubscribe, please follow the instructions >> at http://www.cfczone.org/listserv.cfm >> >> CFCDev is supported by: >> Katapult Media, Inc. >> We are cool code geeks looking for fun projects to rock! >> www.katapultmedia.com >> >> An archive of the CFCDev list is available at >> www.mail-archive.com/[email protected] >> >> > > > You are subscribed to cfcdev. To unsubscribe, please follow the instructions > at http://www.cfczone.org/listserv.cfm > > CFCDev is supported by: > Katapult Media, Inc. > We are cool code geeks looking for fun projects to rock! > www.katapultmedia.com > > An archive of the CFCDev list is available at > www.mail-archive.com/[email protected] > You are subscribed to cfcdev. To unsubscribe, please follow the instructions at http://www.cfczone.org/listserv.cfm CFCDev is supported by: Katapult Media, Inc. We are cool code geeks looking for fun projects to rock! www.katapultmedia.com An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
