Hi Peter, Yes, whatever I do, I'm going to (try to) use the BO's business logic to calculate price.
I follow your ideas, and thanks for them. Now, it's up to me to try things out. Thanks, Jamie On Feb 18, 11:01 am, Peter Bell <[email protected]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
