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