Hi Aaron,
You'd have to lay out all of the details of the use case for us to really
lock this, but let me get you thinking in a direction . . .
>From an object perspective, what is keeping track of the views? Lets say we
are tracking the views of a product - should the product object know how
many times it has been viewed? You COULD add a
ProductService.getTotalViews() and ProductService.incrementTotalViews()
method, but in most cases you're giving the product service a little too
much responsibility here, so you want to have a ViewCounterServie - a
singleton responsible for tracking how many times different objects had been
viewed (you COULD have a ProductViewCounterService and a
ArticleViewCounterService and a CategoryViewCounterService, but for most use
cases that'd be overkill).
Your ProductService should have access to your ViewCounterService (if you
use ColdSpring or LightWire, just use constructor or setter injection to
make it available). Then in your various view methods within the product
service, call ViewCounterService.addView("Product",ProductID) and the
ViewCounterService will add a view of the Product object to whatever
ViewCounter table it uses via the ViewCounterDAO which handles all database
interaction for the ViewCounter object.
That'd be the typical baseline OO approach to something like this.
Make any sense?
Best Wishes,
Peter
> 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?
>
>> 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.
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]
