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

Question

开发环境是SQLServer2008数据库和实体框架的C# 3.5。

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

一切都很好，你彻底地拍了拍自己的背。然后，需要与另一个标志交谈。但是，此符号的工作方式与前一个不同，并要求您的符号类和表存储其他信息。假设需要存储5个新事物(列/属性)，但不幸的是，第一种类型的符号不需要这5个东西。然后，当您想控制每种类型的符号中的10个时，您会发现表中有许多空值。

您的域模型会不断增长，直到您有更多的类，比如符号，每个类代表问题域的不同部分，每个类都在数据库中有一个相应的表。每个类别都有相同的问题，即收集其类型的共同信息，但根本不适合每一种类型的专门化。

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

对于这样一个系统来说，最好的办法是什么？？

我已经和我的同事们详细讨论过这件事，我真的很想知道怎样才能最好地解决这样的问题。尤其是因为这似乎是许多人过去都会面临的一个问题。

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

• 为每个实体创建n个“type”类和表，以便与其共享1到1的关系。
  • 继承得很好。
  • 扩展时最耗时。
  • 很多桌子。

​

• 为每个实体创建一个“扩展属性”表，以保存键值对。
  • 引用的完整性。
  • 可扩展的。

​

• 创建一个全局“扩展属性”表来存储任何实体的属性。(模式: entityType、entityId、key、value、dataType)
  • 超可扩展的。
  • 无法与现有表具有引用完整性。
  • 看起来实体框架不能很好地处理这个问题。

​

你会怎么做?为什么？？

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

Answer 1

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

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

一些一般性的建议:要小心太多的继承--喜欢组合而不是继承。您几乎总是可以重构以避免继承。基本上，您的“专门化”将与符号类解耦，这为您提供了一条创建表层次结构的前进之路。如前所述，头第一设计模式书是一个很好的起点。

而且，不要害怕有一堆类和一堆表。一般来说，灵活的设计倾向于很多类和表(当然，这样做也有缺点--这取决于您决定最佳折衷方案)。