好吧,这对我来说是一个有趣且最重要的真正迫切需要解决的问题……为了让其他人能够理解它,我已经伸展自己做了一个插图很好的帖子.

对象模型

所以我想到了这个简单,容易和“漂亮”的模型.看第一张照片. (你可以忽略PathEntry,它与我的情况无关.)

想法是MediaFeedItem拥有：

> ThumbnailFileEntries的集合(可通过ThumbnailFiles属性访问)
>最多1个原始FileEntry(MetadataFile属性)和
>最多1个MediaFileEntry(MediaFile属性)

我们将这最后三种实体类型称为文件实体.

现在还有更多：正如你所看到的,我从FileEntry继承了ThumbnailFileEntry和MediaFileEntry,让我们不要辩论！ (就目前而言),它是设计的最终故事方面之一,两种实体类型将在以后继续增长.

对于从文件实体到MediaFeedItem的关系引起的多态关联,这已经给我带来了一些重要的问题.

您要注意的第一件事是我已将导出属性从派生文件实体(ThumbnailFileEntry和MediaFileEntry)中删除到主要实体MediaFeedItem.

我这样做是因为他们已经继承了基类FileEntry中定义的属性.如您所见,我不删除这些关联末尾的角色.

关系模型

我将使用极其概念上优越的TPT策略来生成我的对象模型并将其映射到RDB世界(与TPH / TPC相比).

我正在使用EF5-rc,EDMX模型设计师来设计我的模型,使用EF5 DbContext Generator来生成DbContext和POCO,因为我想使用DbContext API.

如您所见,我可以使用EF工具很好地生成数据库模型：

问题

加载新的MediaFeedItem并保存它时,我收到以下错误：

System.InvalidOperationException：违反了Multicplicity约束. “MediaFeedModel.MediaFeedItem_MetadataFile”关系的“MetadataFile”角色具有多重性1或0..1.

我究竟做错了什么？

最佳答案 看一下你的问题,有一点很突出,File和MediaFeedItem之间的FK关系是必需的(IE文件必须有一个MediaFeedItem),但是如果你在File的扩展版本中你可能不想要这个.

我认为你想要做的是以下之一：

>将MediaFeedItem_FileEntry的多重性更改为0..1 – 0..1,以便在任何一端都不需要它
>创建一个新的扩展类型来处理metadataFile类型,并删除基类型和MediaFeedItem之间的直接引用

我个人认为第二种方法是为您的问题创建一个更实际的类型,因为它为您的MetadataFile创建了一个实际的类型

似乎正在发生的是您正在尝试创建扩展类型,但基本类型实际上不是元数据文件.