Hi Jamie, A lot of this depends on how the products get into the system. If it's user input, when you let them add or edit the product, include a getPrice() call to get the updated price and save it to the db - conceptually UPDATE tbl_Products SET Price = #Product.getPrice()# where ID = #Product.getID()# - along with setting the title, description, weight, etc.
If not, I'd still consider running any routine you write through your business object (or IBO if performance becomes a problem). That way getPrice() is the unsurprising and definitive source of the logic for calculating the price of an object. I'd also ask whether anything other than the properties of a given product affects its price. If so, you may need your scheduled task. If not, you just need to add setting the price to the admin add and edit operations and possibly as a step to your product import workflow if you import products rather than entering them manually. And if there *are* external dependencies (change in currency rates by more than a certain amount or changes in prices n a competitors site, rather than an hourly scheduled task, I'd consider some kind of event. Even if you write a script that runs every hour to *see* if the external situation has changed, you'd only fire off the price updating if the business rules required it. Just some general thoughts. Obviously depend on details of your use case . . . Best Wishes, Peter On Feb 18, 2009, at 9:59 AM, Jamie Jackson wrote: > > Thanks Peter, > > The pricing in this system, while it has its share of business logic, > isn't so fickle that pricing changes by the hour, so I think I might > be able to get away with a price-calculating job (which runs over a > query, creates objects which can calculate prices, and populates the > calculated db field) on a sheduled basis. > > I'll think through that one a bit. Thanks for the alternate idea. > > Jamie > > On Feb 17, 6:51 pm, Peter Bell <[email protected]> wrote: >> If the potential number of object instances is small enough, I may >> just load the entire dataset and build the filtering into an AJAX >> front end with the calculated field being "displayed" using a custom >> getter. However, often I'll use a "calculated field" and just add >> that >> field to the list of properties to be persisted. You don't repeat >> yourself in terms of business logic. You just happen to persist the >> results of that business logic to the db for more performant db side >> filtering. >> >> The main "gotcha" to look out for is that if you edit one of the >> fields that your calculated field depends upon you've got to >> automatically (or manually) add your calculated field to the list of >> fields to update in the db. >> >> Either way though, I'd keep the business login in the BO custom >> getter >> which is where I'd expect it to be when looking at someone elses app. >> >> Best Wishes, >> Peter >> >> On Feb 17, 2009, at 6:37 PM, Jamie Jackson wrote: >> >> >> >> >> >>> [I was wondering what happened to my previous attempt at this email, >>> then realized I sent it to [email protected]. Here goes nothin'...] >> >>> I'm sure that this has come up before, so feel free to reply with >>> links or search term suggestions... >> >>> For the people who keep a good deal of business logic in the DB, >>> this >>> question is probably a no-brainer, but for those of you who keep >>> their >>> business logic in their application model (IBO users, users of a >>> Singleton-helper-class-per-hairy-BO, etc.): >> >>> How do you handle a requirement to be able to search on or sort on a >>> calculated field? For instance, OrderableProduct.getPrice() might >>> have >>> (and does, in my project-in-planning) have all kinds of dependencies >>> and calculation gymnastics. >> >>> How could you possibly have both: >>> 1. Performance (how to avoid a general query--a recordset of *all* >>> rows that's then altered/filtered in the app--a seemingly obvious >>> performance problem) >>> 2. DRY business logic >> >>> Maybe this is impossible, and an instance where (copied or moved) >>> business logic necessarily ends up in the database. >> >>> So, how's this done? >> >>> Blech, >>> Jamie > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "CFCDev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/cfcdev?hl=en -~----------~----~----~----~------~----~------~--~---
