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