A community in which webmasters can ask for help with topics such as PHP coding , MySQL , IT jobs, web design, IT security.
Current location:homephp forumphp talk in 2009 yearIs this sound Objected Oriented Design for an e-Commerce site? - page 1
User InfoPosts
Is this sound Objected Oriented Design for an e-Commerce site?#1
I(m pretty new to OOP/OOD, and I realize I have a lot to learn, so I(d like to ask the SO community for their input.

Basically, I(m using CakePHP(s MVC framework, and the online store I(m building is just using 2 models, Category and Product, described by the following CREATE statements:

CREATE TABLE `categories` (
`id` int(11) unsigned NOT NULL auto_increment,
`name` varchar(255) default NULL,
`parent_id` int(11) default NULL REFERENCES categories(`id`),
`lft` int(11) default NULL,
`rght` int(11) default NULL,
PRIMARY KEY (`id`)
);
CREATE TABLE `products` (
`id` int(11) unsigned NOT NULL auto_increment,
`name` varchar(255) default NULL,
`artist_id` int(11) default NULL REFERENCES artists(`id`),
`description` text default NULL,
`category_id` int(11) default NULL REFERENCES categories(`id`),
`status` enum((in stock(, (pre-order(, (out of stock() NOT NULL,
`price` decimal(6,2) default NULL,
`picture` varchar(255) default NULL,
`picture2` varchar(255) default NULL,
PRIMARY KEY (`id`)
);


The online store is going to encompass:


Music

CDs
DVDs

Apparel

Hoodies
T-shirts

Long-sleeve Tees
Babydolls

Hats

Misc Merch

Stickers
Posters
Tote Bags

Downloads

Ringtones
MP3s



Basically, that(s the structure of the category tree, though we may add new categories in the future. Right now all products are treated equally as Product class objects, with their category_id being the only way to distinguish different types of products. The online store is also just one section of the site. The rest of the site contains information such as artist bios and discographies; thus I also have models/tables for: Artist, Album, Track.

Is this a good approach? Or should I be creating separate subclasses for CDs/T-shirts/MP3s/... which inherit from the Product class? I(d like to link each music CD in the store to the discography entry to automatically generate track listings and other information for the product description.

If this is not a good way to go about things, how would you do it instead? Also, what methods/properties should I include in my Category/Product class? And should I only list products in leaf nodes of the category tree?

Edit:
Obviously this design is incomplete. As Cyril pointed out, the Product.price field was missing, and there are still no provisions for sales. I(m actually still trying to work out how best to design & implement those aspects of the store. Most likely, I will just have another model called Orders, but actually processing orders is made more complicated by the fact that we are applying different shipping rates based on shipping destination and what the order contains.

posted date: 2009-04-09 14:46:00


Re: Is this sound Objected Oriented Design for an e-Commerce site?#2
I had made out the solution of this problem. click to view my topic...

hope that hepls.

posted date: 2009-04-09 14:46:01


Re: Is this sound Objected Oriented Design for an e-Commerce site?#3
I like the idea of creating subclasses for each of your major product types. You're going to be doing enough differently for something like a ringtone versus a shippable product that you could well benefit from subclasses. Just my 2 cents though.

posted date: 2009-04-09 16:32:00


Re: Is this sound Objected Oriented Design for an e-Commerce site?#4
Yes, you probably should create separate subclasses for the different types of products, especially if they will have type specific functionality. Like the automatically generating of track listings you mention. But even without that, by using separately named product classes you will make the code more readable and more logical when dealing with product type specific code.You also might want to create a more specific database model.Liketable: productprod_id...common stuff..product_clothesprod_id...Clothes specific stuff...product_musicprod_id...music specific stuff...product_merchprod_id...merchandise specific stuff..Because music doesn(t have a size measured in inches and clothes don(t have a bitrate.

posted date: 2009-04-09 16:37:00


Re: Is this sound Objected Oriented Design for an e-Commerce site?#5
No,You should definitely not create separate subclasses unless you need some mumbo-jumbo magic (like custom t-shirt logos, etc) which cannot be achieved a simple category division). Even in that case you may be safe putting in an extra flag field in the category class (HasLogo for example).But the design does not impress me yet. What kind of store has no provision for sales? What about price field?You could also put the Picture in a separate table for the sake of flexibility.What are you using lft/rght for? You can use a simple Inde property to store the category(s place in the tree, but remember you will need to update each time you delete/add a category.

posted date: 2009-04-09 16:57:00


Re: Is this sound Objected Oriented Design for an e-Commerce site?#6
You should skip the category_id column and model the relationship more like a tag cloud. You will want to associate each product with one or more categories.You should skip the artist_id column and model the relationship more like a tag cloud. You will eventually want to associate some product with multiple artists.Categories are dated, you HAVE to use tag clouds. As a rule you should NEVER create tables with a references statement; UNLESS every column in the table has a references statement.

posted date: 2009-04-09 17:26:00


Re: Is this sound Objected Oriented Design for an e-Commerce site?#7
The lft/rght are required for CakePHP's Tree behavior, which implements an MPTT structure.

posted date: 2009-04-09 18:21:00


Re: Is this sound Objected Oriented Design for an e-Commerce site?#8
I don't think we will have any products associated with more than one category (other than parent categories). And aside from our samplers, each product will only be associated with one artist. But I do have a Tag model setup, I just don't know how I can apply across the site.

posted date: 2009-04-09 18:25:00


Re: Is this sound Objected Oriented Design for an e-Commerce site?#9
And why shouldn't I create tables with references statements? Aren't they inert? I include them just to show the model associations.

posted date: 2009-04-09 18:28:00


Re: Is this sound Objected Oriented Design for an e-Commerce site?#10
I like more a configuration+behavior approach instead of the subclasses. This can be bits of behaviors at the category level. Depending on the scenario, some behaviors could be associated to separate product types, like for something that applies to certain products regardless of the categories. For this last piece Smoking suggestion would also make a lot of sense, since you could have these extra behaviors associated to additional categories. This way as long as you are working with already coded behaviors, you can add new categories indicating which behaviors it will support.A small variation, would be list of behaviors associated to the categories instead of the bits.The additional classes would be for the behaviors, instead of having to mix it all under the product classes. If you need to associate an UI for these extra things, you can relate it to the behaviors, regardless of product types.

posted date: 2009-04-09 18:51:00


Re: Is this sound Objected Oriented Design for an e-Commerce site?#11
+1 for tag clouds approach - mentioned something related to it in my answer.

posted date: 2009-04-09 18:53:00


Re: Is this sound Objected Oriented Design for an e-Commerce site?#12
Having subclasses not always make a system more readable/logical. Of course this vary based on the scenario, but I have seen pretty much identical systems where one followed a subclass approach and the other a configuration based approach and it was a lot easier to understand - added in an answer.

posted date: 2009-04-09 18:57:00


select page: « 1 2 »
Copyright ©2008-2017 www.momige.com, all rights reserved.