在我们基于MVC框架构建的电子商务系统（web）中，团队就产品视图的实现展开了争论。有100多个产品类别（照片/视频、电脑、厨房用具等），每个类别都有自己的特点，如产品明细表、折扣和信用计算器等。每个产品查看页面在每个类别中都略有不同。这种微小但重要的差异必须以某种方式加以实现。
1） 其中一个解决方案是有一个"优步产品视图"页面，适合每个类别。然而，为了正确地显示和隐藏该视图的元素，我们需要一些xml/json来存储配置。
- PROS：影响所有视图的更改都可以轻松完成
- 缺点：很难预测所有参数的组合，表单元素之间的依赖关系，这将使配置文件变得复杂，调试也很困难
2） 另一个建议的解决方案是每个类别有一个视图。
- PROS：无需配置，简单更改，为每个类别量身定制解决方案
- 缺点：为所有页面添加新功能需要很长时间
我还看到1解决方案中有一个CON。我们拥有丰富的HTML/CSS/Javascript语言来实现任何用户界面，包括复杂的表单和验证、向导以及其他产品功能。在使用配置和解析器时，我们使用json/xml-config的poor语言。例如，很难对表单元素之间的依赖关系进行编程。
问题：有更好的方法吗？什么是经过验证的"视图继承"方法？非常感谢。
我会尝试提供"另一种"方法，而不一定是"更好"（我不相信绝对的"更好"或"更差"——对我来说，设计只有在执行时才好，这取决于实现者）。
据我所知，你提出了两种方案。第一种是单片设计，它试图涵盖广泛的职责，但过滤掉不需要的功能。它具有集中的特性，允许您将更改/改进应用于中心实体。
另一种是由许多量身定制的实体组成的设计，每个实体彼此几乎没有共同点，以及更简单的初始设计（但未来需要影响多个产品的改进将是一场噩梦）。
所以这里有另一种方法。它从实体组件系统中获得了一些想法，这些系统在商业世界中很少见，但在游戏引擎中非常常见（更接近我的工作）。
这个想法从前面提到的继承层次结构的经典概念开始，支持组合（仅针对这种情况：继承仍然非常有用）。
您的产品视图实体变成了一个空白容器，它最初根本不输出任何内容。您添加了影响视图的（而不是继承）视图组件。
然后，一个中央"系统"获取该产品视图实体并对其进行处理，检查可用组件并根据可用组件执行适当的功能。在这种情况下，系统往往是最单一的。实体和组件、实体和系统之间没有耦合。实体是完全独立的。组件也是完全独立的。从系统到组件可能存在紧密耦合，从系统到实体可能存在松散耦合。
该系统的优势在于其灵活性，可以轻松处理少数集中组件中潜在的无限数量的组合可能性。新实体可以从现有组件串在一起，只需添加适当的组件，瞧，新实体。产品视图之间的这些细微差异可以通过每个产品视图实体所具有的视图组件的细微差异来解释。
优点：
- 只需添加适当的查看组件，就可以将新的产品视图串在一起
- 仍然为您提供了一个集中的代码库，其中对现有产品类别的更改非常快速和简单（只需修改中心组件或添加新组件）
缺点：
- 这在商业领域是一种非常奇特的方法，尽管在游戏世界中非常常见。因此，团队中的许多人不太可能熟悉它，缺乏熟悉可能会导致困难和学习痛苦
- 倾向于提前完成大量工作，以换取未来的工作量减轻，特别是在查询可用实体组件方面
不幸的是，我不太熟悉您的团队正在使用的工具的精确组合，以了解如何有效地将这样的设计映射到它们。
但这可能会增加讨论内容——"另一种"方法（很难说"更好"）。