在我们建立在MVC框架上的电子商务系统（web）中，团队就产品视图实施进行了辩论。有100多种产品类别（照片/视频，计算机，厨房用具等），每个类别都有其功能，如产品详细信息表格，折扣和信用计算器等。每个产品视图页面略有不同在每个类别中。这种差异尽管很重要，但必须以某种方式实施。
1）其中一个解决方案是拥有一个＆＃34;优步产品视图＆＃34;适合每个类别的页面。但是，为了正确显示和隐藏此视图的元素，我们需要一些xml / json来存储配置。
2）Anther建议的解决方案是每个类别有一个视图。
我在1解决方案中也看到了一个CON。我们有HTML / CSS / Javascript的丰富的语言来实现任何用户界面，具有复杂的表单和验证，向导，其他产品功能。使用配置和解析器时，我们使用json / xml配置的差语言。例如，很难编写表单元素之间的依赖关系。
问题：有没有更好的方法？什么是经过验证的方法，以便继承＆＃39;？谢谢。
答案 0 :(得分：2)
我会尝试提供“另一种”方法，不一定是“更好”（我不相信绝对“更好”或“更糟糕” - 对我来说，设计只是执行得很好，这取决于关于实施者）。
据我所知，你有两个提议的场景。第一种是单片设计，试图涵盖广泛的责任，但过滤掉不需要的功能。它具有集中的特性，允许您将更改/改进应用于中央实体。
另一种是由许多定制实体组成的设计，每个实体与另一个实体几乎没有共同点，并且初始设计更简单（但是需要影响多个产品的未来改进将是一场噩梦）。
所以这是另一种方法。它需要来自实体组件系统的一些想法，这些想法在商业世界中很少见，但在游戏引擎中非常常见（更接近我的工作线）。
这个想法始于前面提到的继承层次结构的经典概念，有利于组合（仅适用于这种情况：继承仍然非常有用）。
您的产品视图实体变成一个空白容器，最初根本不输出任何内容。您添加（不是继承）视图组件会影响视图。
然后，中央“系统”将获取此产品视图实体并对其进行处理，检查可用组件并根据可用组件执行适当的功能。在这种情况下，系统往往是最单一的。实体和组件，或实体和系统之间没有耦合。实体完全独立。组件也完全独立。系统与组件之间往往存在紧密耦合，系统与实体之间存在松散耦合。
该系统的优势在于可以灵活地从少数集中组件中轻松处理潜在无限数量的组合可能性。新实体可以从现有组件串联起来而不需要进一步的代码，而不仅仅是添加适当的组件和新实体。产品视图之间的细微差别可以通过每个产品视图实体的视图组件的细微差别来解释。
优点：
CONS：
不幸的是，我不熟悉您的团队使用的工具的精确组合，以了解如何有效地将这样的设计映射到他们。
但这可能会增加讨论 - “另一种”方法（“更好”很难说）。