我是实体框架的新手，所以希望这是一个非常简单的问题......我可以将这两个实体结合起来吗？
alt text http://img215.imageshack.us/img215/9684/entz.jpg
这是db ... alt text http://img697.imageshack.us/img697/851/52477698.jpg
我希望决赛能够像这样...... alt text http://img694.imageshack.us/img694/88/entss.jpg
答案 0 :(得分：1)
我认为你在问，“我不能将相关实体用作每个层次结构继承的表的鉴别器字段吗？”这是正确的。您需要一个单独的鉴别器字段来使用每个层次结构继承的表。但是，在这种情况下，您可能不需要ResourceType实体，因为实体本身的特定类型足以告诉您使用哪个图标。
但是，我会质疑继承是否是正确的设计。
在O / R映射中使用继承总是有点妥协，因为您将使用类似于每个层次结构的表的设计，它不会自然地映射到格式良好的关系模式，或者像每个类型的表一样的设计，这意味着数据库服务器必须更加努力地提供即使是简单的列表。我认为“Favor composition over inheritance”的通用设计指南尤其对于O / R映射而言比对OOD更为正确。
据我所知，您添加的图片只是举例说明您的问题，而您的真实设计可能更复杂，但让我们以此为例：
图中的子类型（Application，File等）只有一个属性不在父类型中。对于许多子类型，“额外”属性是相同的，Link。其中一个属性具有不同的属性（Filename），但我会注意到文件名可以表示为URI。
除了您在插图中显示的继承设计之外，您还可以在不使用继承的情况下对此设计进行建模。在这种情况下，您将删除子类型，但保留ResourceType实体。
现在让我们考虑一下每个设计的一些示例查询：
// get books with inheritance:
var bi = from b in Context.RelatedResources.OfType<Book>()
select b;
// without
var bc = from b in Context.Resources
where b.ResourceType.ID == ResourceType.Book // static property you define on ResourceType
select b;
两个人都没有让我觉得非常糟糕。对我来说，这就是不使用继承的原因。 O / R映射中继承的最引人注目的优点是能够在单个列表中轻松检索不同子类型的实体。但是你可以用这个设计做到这一点。因为组合设计更容易实现，更简单，并且将更有效地使用您的数据库，我宁愿它，除非继承具有令人信服的优势，我在这里没有看到。