I guess what your saying is a computer is more than the sum of its parts...???
BOb
<i><font color="#663300"><i><font color="#663300">My only point is that instead of associating the price with the Product, let us associate it with the part. The price of the Product may then be calculated from the prices of the assembled parts. That would still keep the sample app simple, yet add more functionality.</font></i>
While there certainly may be businesses where such a relationship makes sense, it doesn't in this case. And while I hate to sound arbitrary, we discussed this last year when we came up with the app design, and now we are finally getting around to implementing the design. I don't want to start changing the design now, or we'll never get it done <b>;-)</b>. There are so many potential variations of this basic design that individual developers will have to be able to adjust their app to meet their client's needs. A sample app can't cover all possibilities; it can simply show how one such design is implemented.
I came up with this app design by basing it loosely on a business problem of a potential client. In their business, they made custom computers from various serialized and non-serialized parts. In this case, the price of the complete system did not match the price of the individual parts; it was based on the traditional base price + options model we all know, and these numbers did not have a 1:1 relationship with part costs.
Think of Products as being the items listed in a catalog for sale. The reason for incuding the Parts at all was to allow for a little deeper logic: when someone orders a Product, we have to be able to make sure that there are enough parts on hand to build it. I wanted to have something more than the traditional and trivial Customers-Orders-Line Items type of demo app.
</font></i>
©2002 Bob Archer |
