One problem I’ve never faced in the projects I’ve worked on is a custom product catalog. I’ve often pondered how product catalogs are modeled. Recently, I started working on a little play project for myself where I am going to face this problem. In fact, one of the reasons I concocted this project for myself was so that I’d get tackle the problem.
While watching Rob Conery’s MVC Storefront series though, I thought, maybe I should “do this in the open.” Let’s solve this problem in public. Let’s define a generic data model for custom product types.
I just posted the scenario to StackOverflow. It’s the perfect place to iterate on this type of thing. Here’s what I posted there. Please join in, I can’t wait to see where this goes!
I want to create a product catalog that allows for intricate details on each of the product types in the catalog. The product types have vastly different data associated with them; some with only generic data, some with a few extra fields of data, some with many fields that are specific to that product type. I need to easily add new product types to the system and respect their configuration, and I'd love tips on how to design the data model for these products as well as how to handle persistence and retrieval.
Some products will be very generic and I plan to use a common UI for editing those products. The products that have extensible configuration associated with them will get new views (and controllers) created for their editing. I expect all custom products to have their own model defined but to share a common base class. The base class would represent the generic product that has no custom fields.
Example products that need to be handled:
- Generic product
- Light Bulb
- Type (with an enum of florescent, incandescent, halogen, led)
- Style (enum of flood, spot, etc.)
- Style (with an enum in the domain model)
- Water Filter information
- Part number
I expect to use MEF for discovering what product types are available in the system. I plan to create assemblies that contain product type models, views, and controllers, drop those assemblies into the bin, and have the application discover the new product types, and show them in the navigation.
Using SQL Server 2008, what would be the best way to store products of these various types, allowing for new types to be added without having to grow the database schema?
When retrieving data from the database, what's the best way to translate these polymorphic entities into their correct domain models?