0

我正在设计一个相当复杂的托管网络应用程序，它需要支持多个彼此有效隔离的“团队”。例如，表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; }
}

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

  1. 这甚至会起作用吗？
  2. 这是一个可怕的想法吗？
4

1 回答 1

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 直接放在所有这些类上，则实际的 DB 结构应该相同。

我个人不会这样做，因为它几乎没有增加价值，并且可能会在未来引起头痛。

相反，如果出于某种原因需要以通用方式与它们交互，则可以在所有这些类上使用 IOfTeam 接口。

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

于 2013-06-19T23:09:08.173 回答