EF中一对多关系下Group实体添加及仓储层使用疑问

我在服务器项目中使用Entity Framework实现了University与Group的一对多关联关系，相关代码如下：

实体类 #

public class University
{
    public int Id { get; set; }
    public string Title { get; set; }

    public IEnumerable<Group> Groups { get; set; }
}

public class Group
{
    public int Id { get; set; }
    public string Number { get; set; }

    public int UniversityId { get; set; }
    public University University { get; set; }
}

University仓储类 #

public class UniversityRepository : IUniversityRepository   
{       
    private readonly ApplicationDbContext dbContext;        
    
    public UniversityRepository(ApplicationDbContext dbContext)          
    {           
        this.dbContext = dbContext;          
    }       
    
    public async Task<int> Create(University entity)        
    {
        await dbContext.Universities.AddAsync(entity);          
        await dbContext.SaveChangesAsync();              
        return entity.Id;       
    }   
}

实体关系配置 #

public void Configure(EntityTypeBuilder<University> builder)
{
    builder.HasMany(b => b.Groups)
        .WithOne()
        .HasForeignKey(g => g.UniversityId)
        .OnDelete(DeleteBehavior.Cascade);
}

我目前不清楚如何添加新的Group实例，现有两个负责CRUD的仓储类。是否需要在同一个服务中同时使用两个仓储，为Group的UniversityId、University字段赋值，同时将Group实例添加到已存在的University的Groups集合中？此外，一个数据访问服务中可包含多少个仓储？一个仓储可访问多少张数据表？我的做法是否正确？

1. 添加新Group实例的方法 #

有两种实用方案：

• 直接通过Group仓储添加
  只需给Group的UniversityId赋值为目标大学的ID，调用Group仓储的Create方法即可。无需手动将Group加入University的Groups集合——EF会自动维护关联关系，后续查询University时能自动加载对应的Groups。
  示例代码（假设Group仓储有Create方法）：

public async Task<int> CreateGroup(int universityId, string groupNumber)
{
    var group = new Group
    {
        Number = groupNumber,
        UniversityId = universityId
    };
    await _groupRepository.Create(group);
    return group.Id;
}

• 通过University关联添加
  若需从University视角管理关联，首先要把University的Groups属性改为List<Group>或ICollection<Group>（IEnumerable不支持添加操作）。然后查询目标University实例，将新Group加入其Groups集合，最后调用University仓储的Update方法（或直接SaveChanges，EF会跟踪实体变化）。这种方式多了一次数据库查询，适合需要同时更新University其他属性的场景。

2. 服务中仓储的数量限制 #

没有硬性规定，完全看业务需求。如果一个业务操作需要涉及多个实体的CRUD，就可以在同一个服务中注入多个仓储。比如添加Group前要验证University是否存在，就可以同时注入GroupRepository和UniversityRepository，先查询确认大学存在再创建Group。

3. 单个仓储可访问的数据表数量 #

仓储设计的核心是围绕业务聚合根，通常一个仓储对应一个聚合根（主实体+关联子实体），但技术上没有强制限制。不过不建议一个仓储操作太多无关数据表，否则会违背单一职责原则，导致逻辑臃肿难维护。比如University仓储可处理University及其关联Group的操作（若把Group作为University的子实体），或者Group单独用自己的仓储，根据业务边界决定。

4. 当前做法的合理性 #

整体方向正确，有几个细节可以优化：

• 将University的Groups属性从IEnumerable<Group>改为List<Group>或ICollection<Group>，支持添加/删除等集合操作，EF跟踪实体变化更顺畅。
• 实体关系配置中，把WithOne()改为WithOne(g => g.University)，明确指定反向导航属性，让EF的关系映射更清晰：

builder.HasMany(b => b.Groups)
    .WithOne(g => g.University)
    .HasForeignKey(g => g.UniversityId)
    .OnDelete(DeleteBehavior.Cascade);

内容的提问来源于stack exchange，提问作者Pavka