diverse product support

[Dennis]

Hi,

I want to use this framework to make an ecommerce shop (what else ) but I was wondering what the recommended way is for supporting a lot of different products with different attributes?

For example for a toy store you can have the general attributes like size, color, price etc.
But atributes for a doll are different the a racetrack.

Do I just extend ProductImpl with all the properties I can think of, of all the products, and let it store in one big table, where then not every column in the DB is fileld (depending on the producttype) ? What is the recommended way?

Gr. Dennis

[bradford.taylor]

I would recommend utilizing ProductAttribute and it's Impl or SkuAttribute and it's Impl.

Before I explain what that is I want to point out something: It's our recommendation to use Products to define specific products and SKUs do define variations in that product. Given a hat that comes in red or blue you would create a Product for the hat and then two SKUs. One SKU would be the red hat and another SKU would be the blue hat.

Product Attributes allow you to define attributes specific to an individual product. The BLC_PRODUCT_ATTRIBUTE table has a Many To One relationship to the BLC_PRODUCT table so a Product can have many attributes. This functionality was put in place so that users of the framework could specifically define attributes on specific Products without having to extend the framework.

The same concept applies to SKU Attributes.

Take a look at these items and let me know if you have any questions regarding it.

[Dennis]

thanks for the pointer, I'll check it out and get back to you.

[Dennis]

Okay, I looked at the code,the documentation on the wiki and your post above.

I understand the difference between a Product and an SKU.
However, what I do not understand is where to put the attributes. In the SKU or the product, or both?


For example your hat product. If the variations of the product are defined in the SKU, then what is left to put in the Product?
I mean; the attributes/fields of a class define it's state, so the things all hats have in common should be put in the Product and the rest in an SKU.

That only leaves the category to be put in the product, since a price, the size, the color, a description, a model etc etc, all are variations of the hat product.
Am I right in this one? Can yu give an example of how you would use SKU(Attributes) and Product(Attributes)?

I read somewhere, in the code I believe, that an SKU represents the sellable counterpart of the product with the attributes. Is that true?

[Dennis]

Hi Bradford,

is there any change you have an answer for me soon? I'd like to get started on development during my christmas holiday
If you don't have any time and are enjoying the xmas season, I totally understand

For all of you: have a nice Xmas and a good 2010!!

[bradford.taylor]

Short answer to your question is that attributes shared by all variations of a product, for example Manufacturer, would be a product attribute while attributes specific to the SKU, for example color, would be SKU attributes. A more detailed explanation is below.

The goal of the Product/SKU, Attribute/Extend architecture of the framework is maximize flexibility for the implementer. Our conversation has lead to two major questions. First, When do you use SKU vs Product? Second, when do you use an Attribute vs Extending an object?

SKU vs Product
It is common for retailers to use a one to one relationship between Product and SKU. Conceptually they only have Products. This is implemented in the framework as a Product with a single SKU. This is reflected in the currently initial implementation of the Admin Tool in that it allows you to create a Product and assign a price to that Product. Under the covers it actually creates a single SKU for that Product.

Other companies use master products with SKUs representing variations of those Products. Since both Products and SKUs have attributes there can be more than one way to implement whether that attribute is associated with the Product or the SKU. This is up to the implementer as to what is desired.

Extend vs Attributes
The next question is when do you use Product/SKU attributes versus extending the object implementation (such as ProductImpl)? In general Attributes are provided for "convenience". We wanted to provide the ability to add less significant attributes to Products or SKUs without having to extend an object.

The best use of attributes is for a small number of widely varied attributes.

It is better to extend the ProductImpl or SKUImpl when properties are shared by a large number of Products or SKUs. In an extreme example you could extend the ProductImpl for each type of product you have; so for a store that sold clothes and jewelry you could have MyStoreClothingImpl and MyStoreJewelryImpl each having attributes specific to them. This is not a recommended way of implementing attributes due to the complication but should be possible.

There are some considerations to take into account when deciding how to implement.

1) Table based attributes are not indexed for searching.
2) Performance will be better with extending the Product or SKU Impl since you have additional queries, joins and rows in the database for attributes. This performance "penalty" is negligible for a small number of attributes (hence the recommendations above).

I hope this has provided guidelines for when and how to use Product, SKUs, object extensions and attributes. Please let me know if you have additional questions.

Bradford Taylor

[Dennis]

Hi Bradford,

thank you for the thorough explenation.
With this information I'll try to model my domain for my implementation.

However, expect me to return with some questions. Especially related to your final remarks about the clothes and jewelry shop.



Okay, already one up front
The way you advice against the implementation of the jewelry and clothes shop, is exactly the way I had in mind to implement this domain.....How else can you model the jewelry and clothes shop then? How can you determine if the user bought a piece of jewelry or a shirt? With seperate implementation classes you can figure it out. Without, I guess you put an ENUM in a product or sku attribute which denotes it is a piece of jewelry or a shirt???

Greetz Dennis

[Dennis]

I really like to start using this framework, so let's make it concrete

What I want to create it a shop with sanitary/plumbing products. Like toilets, sinks, showerheads, bathroom furniture.
Can you give a high-level example of the domainmodel with products/skus/attributes using these items?

In a usual domainmodel we would have for example:

toilet
============
brand
model
factory number
price
color

sink
============
brand
model
factory number
price
color
width
depth

showerheads
============
brand
factory number
water_per_second
price
color

bathroom furniture
============
brand
color
factory number
style
width
height
depth
price


All of these have some properties in common, only price, brand and factory_number are shared across every product...
I have some idea how to model this using products/sku/attributes, but I want to reflect it to your ideas. Can you help me here?

Thanks!

[bradford.taylor]

I wanted to let you know that I saw your post. I'm tied up with some tasks right now but when I get some time I'll get you a response.

[Dennis]

thank you!