> I would start off with an array of strings, which is the simplest
> thing that could possibly work (or the simpler of the two options, at
> least).
Though I generally agree with the idea of going with the "simplest thing
that could possibly work", in this case, I'm not so sure storing the line
item in a string works.
By way of explanation, a typical order item is usually composed of the
following information:
ID - Internal database assigned ID.
SKU - Usually assigned by the bookkeeping system.
This might actually be derived from the options
or units that the user chose.
Name - Human readable name. It could be the same as
the name as it appears in the catalog or a
concatenation of the name and the options chosen,
or the name associated with a specific SKU.
Quantity - How many the user wants. Usually an
Integer value though not always.
Unit Price - Again, this could be the item price,
calculated based on options the user chose, or
associated with a specific SKU.
Total - Usually, it's just Quantity * Unit Price...
but not always.
At the bare minimum, you need to know the item ID and quantity to calculate
the rest of the information. In fact, when the user initially adds an item
to their cart, you'll need to perform these calculations. However, it's
generally better to store the derived value rather than re-calculate the
values every time you need them.
The reason is not performance related. It's because you want to capture the
order in a specific state. For instance, an item's price might change over
time. It could, in fact, change from the time a customer order the item to
the time the vendor was able to fulfill the order.
You can, of course, never change or delete a record. Every time the vendor
makes a change to an item, you archive the previous item and add a new one.
However, that's generally far more complicated. And, it doesn't take into
account another very good reason to store derived values: sometimes, price
can't be calculated. Sometimes, a sales person needs to log in and give a
customer a discount just because.
So, even in this relatively simple order (which doesn't take into account
shipping, discounts, packages, etc.), we've got several pieces of distinct
information. Several pieces of information mean we need a data structure. We
could store those values in a delimited string, but that's more difficult
and tedious than using structures:
Total = listGetAt(orderItem, 4) * listGetAt(orderItem, 5)
As opposed to:
Total = orderItem.quantity * orderItem.price
So, I think the simplest solution that works is structures. But, there are
other factors that might push us to a more object oriented solution.
Semantically, the following is more obvious than either of the above:
Total = orderItem.getTotal()
That also keeps the calculation (rudimentary though it is), in the orderItem
component. That way, if we add line item discounts, the getTotal() method
can take care of it and the rest of the code is none the wiser.
> You can always switch from structures to objects as you design
> grows, especially since such changes should be insulated by your Order
> object.
Order items will usually need to be displayed at various points in the user
interface (checkout, admin interface, e-mail notifications, etc.). Assuming
your display logic is not in your Order component, there's going to be code
sprinkled throughout the app that needs to know how to enumerate the order
items. If you use a data structure, then that code may also need to know how
to calculate price.
Ben Rogers
http://www.c4.net
v.508.240.0051
f.508.240.0057
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to
[email protected] 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).
CFCDev is supported by New Atlanta, makers of BlueDragon
http://www.newatlanta.com/products/bluedragon/index.cfm
An archive of the CFCDev list is available at
www.mail-archive.com/[email protected]
