实体类别; 类似的遗产问题
除了工作之外，我和一些朋友正在努力建立各种游戏; 我们构建其中一些方法的方式对于正常的面向对象方法非常有效，但是正如大多数开发人员将certificate的那样，并不总能将自身很好地转换为数据库持久化方法。
这不是我们所拥有的绝对布局，它只是为了表示而给出的样本模型。
整个项目都是在C＃4.0中完成的，我们都打算使用Entity Framework 4.0（除非Fluent nHibernate能够真正为我们提供我们在EF中无法做到的事情）。
我们一直在运行的问题之一是inheritance数据库模型中的东西。 使用Entity Framework设计器，我可以绘制下面的代码; 但我确信很明显，它不像预期的那样有效。
澄清一点; ‘物品’有奖金，可以是任何东西。 因此，游戏的每个部分都必须从类似的东西中衍生出来，这样无论什么“改变”，它都处于足够基本的水平。 听起来相当简单明了，对吧？
那么，我们从’Unit’inheritance了与游戏相关的所有内容。 权重，度量，随机（想象骰子，也许？），还有其他这样的实体。 其中一些是相似的，但在代码中，它们每个都会有不同的反应。
我们在将这种事物抽象到数据库模型中时遇到了一个非常大的问题。 如果没有“Enum”支持，很难将其转换为仍然共享共同列表的多个表。 我们描述的一种解决方案是使用“密钥环”类型方法，其中附加到字符的所有内容都存储在带有“密钥”的“环”上，其中每个密钥具有表示类型的值。 这在function上起作用，但我们发现它变得非常缓慢并且表现不佳。 我们也不喜欢这种方法，因为它开始觉得好像所有东西都被“倾倒”在一个类中; 这使得管理和逻辑结构难以遵守。
我希望其他人对我能解决这个问题有什么想法。 它真的把我推到了墙上; 总结一下 ; 目标是构建一个类型（单元），可以用作基本类型（每个类型的表），用于跨相对全局范围的通用引用 ，而不必将所有内容转储到单个集合中。 我可以使用一个接口来确定实际行为 ，这不是一个大问题。
alt text http://img171.imageshack.us/img171/5153/modelg.png
这与entity framework中表达的“大致”相同。
alt text http://img684.imageshack.us/img684/6454/entities.png
您是否尝试过针对单位的每个混凝土类型的映射？ 即使用Id字段链接Measure，Weights和Random表？ （每个都有一个Id列，它们通过这个相关联。）
我认为你在Sheet和Measure之间展示的关系在Table per class mapping中会有问题。 如果单位’度量’的类型类型由单位中的鉴别器列确定，则工作表无法映射到仅测量。 使用TPCT，您可以将Sheet映射到Measures成功，因为它可以使用Id来“返回”Units表。
遗憾的是，TPCT的示例很少：有时似乎需要进行一些{编辑模型，导出数据库，在SSMS中进行更改，导入数据库}的迭代……以使其正确。