Question

我正在设计一个相当复杂的托管网络应用，需要支持多个彼此有效隔离的“团队”。例如，表格People，Areas，Reports等将由公司A，B，C和团队以及用户填充的数据混合在一起从公司A登录后，他应该只看到与公司A相关的数据。我的计划是在Team和（几乎）所有其他类型之间建立关系，并使用存储库访问所有其他类型，并始终查询TeamId与登录人员的TeamId匹配的位置。

因为我想拥有

[ForeignKey("Team")]
public int TeamId { get; set; }
public virtual Team Team { get; set; }

在几乎每个类上，我都认为将它们放在抽象类中并继承这些属性可能会很好：

public abstract class OfTeam {
    [ForeignKey("Team")]
    public int TeamId { get; set; }
    public virtual Team Team { get; set; }
}

public class Person : OfTeam {
    [Key]
    public int Id { get; set; }
    public string Name { get; set; }
}

但是，我意识到这不是继承的真正含义。所以我想知道

这会不会起作用？
这是一个糟糕的主意吗？

Answer 1

我起初误解了，虽然你是继承团队，但这本来是个坏主意。

如果你曾经查询过db.OfTeam，那么它会将每一个从它继承的表联合起来，这将表现得非常糟糕。向下滚动以查看此处生成的SQL： http://weblogs.asp.net/manavi/archive/2011/01/03/inheritance-mapping-strategies-with-entity-framework-code-first-ctp5-part-3-table-per-concrete-type-tpc-and-choosing-strategy-guidelines.aspx

否则，实际的数据库结构应该与您直接将TeamId / Team放在所有这些类上相同。

我个人不会这样做，因为它增加的价值很小，可能会导致头痛。

相反，如果由于某种原因需要以通用方式与它们进行交互，那么你可以在所有这些类上都有一个IOfTeam接口。

作为旁注，我做了类似的事情，通常将TeamId缓存到易于访问的地方，这样我就可以在任何地方执行CurrentIdentity.TeamId并将其传递给查询。这允许像GetPeople这样的存储库模式上的方法在返回IQueryable之前应用where过滤器的where条件。

这是EF Code First中TPC继承的合法使用吗？

1 个答案: