高度可扩展项目的设计问题 - 牢记最佳实践

Question

开发环境是 C# 3.5，带有 SQL Server 2008 数据库和实体框架。

假设您有一个名为 Sign 的类和一个表，它表示由您的软件需要控制的第三方创建的物理电子标志。您还有一个名为 SignDriver 的类，它负责与标志进行实际通信。 Sign 的属性/列表示 Sign Driver 正确与标志对话所需的可配置信息。

一切都很好，你已经非常彻底地拍了拍自己的后背。然后需要与不同的星座交谈。但是，此标志的工作方式与前一个不同，需要您的 Sign 类和表来存储其他信息。假设需要存储 5 个新东西（列/属性），但不幸的是，第一种类型的符号不需要这 5 个东西。然后你会发现，当你想控制每种类型的 10 个符号时，你的表中有很多 NULL 值。

您的域模型会不断增长，直到您拥有更多像 Sign 这样的类，每个类都代表您的问题域的不同部分，并且每个类在您的数据库中都有一个对应的表。每个班级都面临着收集其类型的共同信息的相同问题，但根本不能很好地满足每种类型的专业化。

您意识到您的问题的性质意味着将有更多类型的迹象需要控制，以及更多类型的其他实体需要迎合。您需要一个更可扩展的模型。

对于这样的系统，最好的方法是什么？？

我已与我的同事详细讨论过这个问题，并且真的很想知道解决此类问题的最佳方法是什么。尤其是因为这似乎是很多人过去都会遇到的问题。

以下是我们提出的选项以及关于每个选项的一些要点：

• 为每个实体创建 n 个“类型”类和表，以与其共享 1 对 1 关系。
  • 非常继承-y。
  • 扩展时最耗时。
  • 很多表。
• 为每个实体创建一个“扩展属性”表以保存键值对。
  • 参照完整性。
  • 可扩展。
• 创建一个全局“扩展属性”表来存储任何实体的属性。 （架构：entityType、entityId、key、value、dataType）
  • 超级可扩展。
  • 不能与现有表保持参照完整性。
  • 看起来 Entity Framework 不能很好地处理这个问题。

你会做什么？为什么？

非常感谢任何帮助。 干杯。

Answer 1

这个问题涉及软件设计的多个问题。

您的主要问题似乎是将继承层次结构映射到您的数据库表。这已被广泛分析 - 请参阅 Martin Fowler 在他的“企业架构模式”一书中的工作。你可以得到一些简短的概述here，但这本书更好，应该放在每个 OO 开发人员的书架上。比较“每个子类的表”和“每个类层次结构的表”模式。

一些一般性建议：小心过多的继承 - 优先组合而不是继承。您几乎总是可以重构以避免继承。基本上，您最终会获得与 Sign 类分离的“专业化”，这为您提供了创建表层次结构的方法。如前所述，Head First Design Patterns 这本书是一个很好的起点。

另外，不要害怕有成堆的类和成堆的表。一般来说，灵活的设计有利于很多类和表（当然这样做也有缺点 - 由您决定最佳折衷方案）。