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