EF 代码优先 - WithMany()

发布于 2024-11-05 18:04:10 字数 516 浏览 0 评论 0 原文

我最近来到了 ManyNavigationPropertyConfiguration ,在该类中我发现了一个名为 WithMany() 的方法,有 2 个重载。

第一次重载: WithMany()

将关系配置为 许多:许多没有导航 另一边的财产 关系。

第二次过载: WithMany(Expression>)

将关系配置为 许多:许多具有导航属性 在关系的另一边。

现在我的问题是,为什么要在没有导航属性的情况下将关系配置为“many:many”(第一个重载)?我没有看到任何有帮助的场景......有什么想法吗?

I recently came by the class ManyNavigationPropertyConfiguration<TEntity, TTarget>
, and within that class there I found a method named WithMany() with 2 overloads.

The first overload:
WithMany()

Configures the relationship to be
many:many without a navigation
property on the other side of the
relationship.

The second overload:
WithMany(Expression<Func<TTarget, ICollection<TEntity>>>)

Configures the relationship to be
many:many with a navigation property
on the other side of the relationship.

Now is my question, why would you configure a relationship to be many:many without a navigation property (the first overload)? I dont see any scenarios where that would be helpful... Any thoughts?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

朱染 2024-11-12 18:04:10

一个例子可能是这个模型:

public class User
{
    public int UserId { get; set; }
    public string Name { get; set; }
    public ICollection<Role> Roles { get; set; }
}

public class Role
{
    public int RoleId { get; set; }
    public string Description { get; set; }
}

如果您从来没有兴趣检索具有特定角色的所有用户,则将导航属性......添加

public ICollection<User> Users { get; set; }

Role类将是不必要的开销。

但是您仍然必须 EF 告诉 UserRole 之间存在多对多关系……

modelBuilder.Entity<User>()
            .HasMany(u => u.Roles)
            .WithMany();

因为默认约定映射会创建错误的关系,即一对多关系,对应这样的映射:

modelBuilder.Entity<User>()
            .HasMany(u => u.Roles)
            .WithOptional();

An example might be this model:

public class User
{
    public int UserId { get; set; }
    public string Name { get; set; }
    public ICollection<Role> Roles { get; set; }
}

public class Role
{
    public int RoleId { get; set; }
    public string Description { get; set; }
}

If you are never interested to retrieve all users which are in a specific role, adding a navigation property ...

public ICollection<User> Users { get; set; }

... to the Role class would be unnecessary overhead.

But you still must EF tell that a many-to-many relationship between User and Role exists ...

modelBuilder.Entity<User>()
            .HasMany(u => u.Roles)
            .WithMany();

... because the default convention mappings would create a wrong relationship, namely a one-to-many relationship, corresponding to this mapping:

modelBuilder.Entity<User>()
            .HasMany(u => u.Roles)
            .WithOptional();
甜宝宝 2024-11-12 18:04:10

请注意,导航属性的选择位于目标的另一侧。

让我们看一个例子,尽管这个具体案例可能不是我观点的完美说明者...如果您想跟踪数学测试并重复使用问题,您可能有两个表(Tests< /code> 和 Questions) 具有多对多关系;每个测试有几个问题,每个问题可以出现在多个测试中。但是,您可能永远不需要获取特定问题所涉及的测试集合 - 即使您知道问题可能出现在多个测试中,但您对哪个测试不感兴趣。
因此,您在声明时使用 .WithMany() 重载,这样您就可以获得一个导航属性来获取测试问题 (theTest.Questions()),但没有另一种方式是导航属性 (theQuestion.Tests())。但您仍然需要多对多关系,因为测试和问题都可以有许多其他关系。
我同意,在这种特定情况下,这种设置可能没有意义,但肯定有一些情况是有意义的,在这些情况下, .WithMany() 重载让您无需定义属性(和每一个的 lambda 表达式)你永远都不需要。

Note that the choice for a navigation property is on the other side of the target.

Let's look at an example, even though this specific case might not be the perfect illustrator of my point... If you want to keep track of math tests, and re-use questions, you might have two tables (Tests and Questions) which have a many-to-many relationship; each test has several questions, and each question can appear on several tests. However, you might not ever need to get a collection of tests that a specific question is on - even though you know that questions can appear on more than one test, you aren't interested in which.
Thus, you use the .WithMany() overload when declaring this, so you get a navigational property to get the questions of a test (theTest.Questions()) but no navigational property the other way (theQuestion.Tests()). But you still need a many-to-many relationship, since both tests and questions can have many of the other.
I agree that in this specific case this setup might not make sense, but there is certainly cases where it does, and in those cases the .WithMany() overload lets you get by without defining properties (and a lambda expression for each one of them) you'll never need.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文