2

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

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

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

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

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

对于这样的系统，最好的前进方式是什么？

我已经与我的同事详细讨论了这个问题，并且真的很想知道解决此类问题的最佳方法是什么。特别是因为这似乎是许多人过去会面临的问题。

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

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

你会做什么，为什么？

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

4

1 回答 1

2

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

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

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

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

于 2010-02-12T07:42:40.227 回答