MVC：添加一个时创建相关实体答案

【问题标题】：MVC: Create relate entitiy when add oneMVC：添加一个时创建相关实体
【发布时间】：2012-10-18 20:31:30
【问题描述】：

所以，我的数据库现在看起来像：

Comment -> Commentable 

Commentable -> News
Commentable -> Files
Commentable -> Photo

这意味着，当我添加新实体（文件或照片）时，我必须添加新的 Commentable 并将此值插入实体。

这方面的最佳做法是什么？我应该覆盖实体的创建功能，还是将其放入存储库添加功能？

表的结构是这样的，因为我不需要为每个实体创建自己的 cmets 表。

编辑：我的表格架构如下：One table vs multiple tables 在 Branko Dimitrijevic 帖子中

当我想添加新文件或事件时——首先，我必须生成新的“可评论”行，然后才能添加关联我的实体。

那么，我的问题是，我必须把这个逻辑放在哪里，或者如何在最正确的实践中做到这一点？

谢谢。

【问题讨论】：

恐怕我对这个问题感到困惑。你能解释得更详细一点吗？
我需要添加新实体 Commentable，当添加照片或文件或新闻时，这意味着，我必须首先创建可评论，获取此 ID，然后将此值设置为新文件的关系或照片。

标签： .net asp.net-mvc entity-framework

【解决方案1】：

仔细考虑照片、新闻和文件表格的设计。当我发布我的第一个 Stackoverflow 问题时，我正在考虑类似的问题：Database design - articles, blog posts, photos, stories。

我意识到文章、照片、视频、文档和博客帖子都共享一些公共字段，例如作者、发布日期、标题、描述、关键字等。所以我创建了一个表的超类型/子类型层次结构，使用 EF 的类型继承特性对其进行建模。然后 cmets 只有一个超类型 talbe（我将其命名为 Publications）的外键。在大多数情况下，这对我来说效果很好。

如果您使用 EF 的继承，请注意：有 2 个变体：Table-per-type (TPT) 和 Table-per-heirarchy (TPH)，每个都有问题：

TPT：为公共字段提供一个超级表，为每个子类型的属性提供一个单独的数据库表。当您查询超类型时，这会出现性能问题（有时很严重）。一种解决方法是创建一个视图以将超类型表引用为不同的实体（这就是我所做的），但它比你想要的有点混乱

TPH：没有性能问题，但该解决方案本质上将层次结构扁平化为一张表。 DBA 和 DB 纯粹主义者，我发现，真的不喜欢你这样做。

【讨论】：

【解决方案2】：

您不需要这样做。如果您有正确的模型结构，EF 会这样做。

public class Comment
{
  public int ID { set;get;}  
  public string Author { set;get;}
  public IEnumrable<CommentContent> CommentContents
}
public class CommentContent
{
  public int ID { set;get;}  
  public string Photo { set;get;}
  public string News{ set;get;}
  public int CommentID { set;get;}
}

现在为您的模型设置属性（包括子表）并执行 SaveChanges，EF 将负责在子表上设置父 ID。

var model=new Comment();
model.Author="Scott";
model.CommentContents.Add(new CommentContent
                                 { Photo="abc.jpg", News="Some content"});
model.CommentContents.Add(new CommentContent
                                 { Photo="abc3.jpg", News="Some content2"});
yourDbContext.Comments.Add(model);
yourDbContext.SaveChanges();

【讨论】：

对不起，我的数据库结构像这里的图片：stackoverflow.com/questions/10602562/…

【解决方案3】：

了解您要达到的目标的“官方”术语可能会有所帮助，这样您就可以进行进一步的研究。它是多态关联。请注意，它通常被认为是anti-pattern。我曾经在 StackOverflow 上向 question 询问过它们，其中的第一张图片可能是您实现它的方式：

这是根据 Bill Karwin 的建议，如果你仍然使用它，如何实现这个 anti-pattern（就像我自己一样，对我来说，这只是一个模式）。

事实上，这就像 Faust 的 TPT 解决方案（如果它适合您，您应该接受它作为答案），特别是如果您使用三个类共有的所有属性扩展基表。

在这种情况下，我更愿意在存储库 Add 函数中处理它，在每个函数中都会为您添加的实体创建评论对象。

【讨论】：