C# 首先在EF代码中使用附加属性的多对多

我在两个实体之间有一种多对多的关系。为了简单起见，我的实体是

class User
{
 int Id;
 string Name;
}

class Roles
{
 int Id;
 string Name;
}

我已经创建了带有一个附加属性的链接实体来链接这些属性，如下所示

class UserRole
{
 int Id;
 User user;
 Role role;
 DateTime created;
}

我知道一种方法是在

User

和

Role

实体中创建

用户角色的
列表
，以实现多对多关系。这是很好的定义

在这里，要获取角色中的用户列表，您可能需要编写如下内容

 User.UserRole.Where(r=>r.Role.Id = 1);

然而，我发现另一种方法不是定义
用户
和
角色
之间的关系，即在这两个实体中都没有
用户角色
的
列表。要访问相关数据，可以使用
UserRole
实体

因此，要在这里获得列表，您需要

 UserRole.Include(u=>u.User).Include(r=>r.Role).Where(a=>a.Role.Id = 1)

编辑：

我喜欢第一种方式，但我担心有多种方式可以创建关联

1） 您可以仅使用
User
属性集创建
UserRole
。然后创建一个新的
角色
，并将新创建的
用户角色
添加到
角色的
列表

2） 另一种方法是创建
用户
和
角色
（无需为
角色
设置
列表
）。然后创建一个
UserRole
并设置
User
和
Role

我不知道该怎么办？是否应该导航链接的实体以检索数据？
在这种情况下，我认为没有理由不使用链接的实体。至少它们是有用的导航属性。根据个人偏好，我建议从
User
或
Role
开始，然后从那里开始导航，因为它们是聚合根（取决于上下文）而且永远不会出现在这些根的上下文之外引用
UserRoles
的情况。@David我同意使用链接实体。然而，我更关心的是使用链接实体进行导航。这仅仅是一个偏好的问题，还是有任何已定义的最佳实践？好吧，这方面的最佳实践可能是从聚合根导航，以及简单地维护逻辑业务域。“你为什么要担心在一处房产中航行？”大卫我用我的担心补充了更多细节。看看它是否有意义。更新中的第一个选项没有多大意义，仍然从领域驱动的设计角度考虑。如果
用户
和
角色
是模型，那么从逻辑上讲，如果这两个角色不同时存在，那么它们之间就不可能存在关联。我仍然认为没有理由不使用导航属性，而不是将每个对象视为聚合根来污染域。