Versatile view vs. Multiple specialized views

Question

In our e-commerce system (web) built on the MVC framework, the team got into a debate over the product view implementation. There are 100+ product categories (photo/video, computer, kitchen appliances etc), and each category has its features like product detail form, discount and credit calculators, etc. Each product view page is slightly different in each of categories. This difference, small albeit important, has to somehow be implemented.

1) One of the solution is to have one "Uber Product View" page which will suit every category. However, to properly show and hide elements of this view, we'll need some xml/json to store configuration.

• PROS: changes affecting all views can be easily done
• CONS: hard to predict all combinations of parameters, dependencies between form elements, that will make config files complex and debugging will be hard

2) Anther proposed solution is to have one view per category.

• PROS: no config, simple changes and tailored solution for each of categories
• CONS: adding new feature to all pages will take long as hell

I see also one CON in the 1 solution. We have the rich language of HTML/CSS/Javascript to implement any user interface, with complex forms and validation, wizards, additional product features. When using the configuration and parser, we use the poor language of json/xml config. It will hard to program dependencies between form elements for example.

Question: is there any better approach? What is a proven approach for 'view inheritance'? Thank you.

Answer 1

I will try offering "another" approach, not necessarily "better" (I don't believe in absolute "better" or "worse" -- to me a design is only as good as it is executed, and that depends on the implementors).

From what I've understood, you have two proposed scenarios. The first is a monolithic design which tries to cover a wide range of responsibilities but filters out unwanted functionality. It has centralized qualities that allow you to apply changes/improvements to a central entity.

The other is a design which consists of a lot of tailored entities, each one having little in common with the other, and a simpler initial design (but future improvements that need to affect multiple products will be a nightmare).

So here's another approach. It takes some ideas from entity-component systems which are kind of rare in the business world but extremely common in game engines (closer to my line of work).

The idea begins by foregoing classical notions of inheritance hierarchies in favor of composition (just for this case: inheritance is still very useful).

Your product view entity turns into a blank container which initially outputs nothing at all. You add (not inherit) view components which affect the view.

A central "system" then takes this product view entity and processes it, checking for available components and executing the appropriate functionality based on the components available. Systems tend to be the most monolithic in this case. There's no coupling between entity and component, or entity and system. Entities are completely independent. Components are also completely independent. There tends to be potentially tight coupling from system to component, and loose coupling from system to entity.

The strength of this system is based around the flexibility of easily tackling a potentially infinite number of combinatorial possibilities from a handful of centralized components. New entities can be strung together from existing components with no further code than just adding the appropriate components and voila, new entity. Those subtle differences between product views can be accounted for by the subtle differences in what view components each product view entity has.

PROS:

• String together new product views by just adding the appropriate viewing components.
• Still gives you that centralized codebase where changes to existing product categories are fairly quick and easy (just modify the central components or add new ones).

CONS:

• This is a pretty exotic approach in a business domain, albeit extremely common in the gaming world. As a result, it's unlikely that many in your team will be familiar with it, and a lack of familiarity could lead to hardships and learning pains.
• Tends to take a lot of work upfront in exchange for alleviating work in the future, particularly with respect to the querying of available entity components.

Unfortunately I'm not very familiar with the precise combination of tools your team is using to know how to effectively map such a design to them.

But this might be something to add to the discussion -- "another" approach ("better" is hard to say).