.NET API中一对多关系（护理-分类）数据添加最佳实践咨询

我正在开发美容沙龙网站的后台管理模块，美容师可添加新护理项目（Care），每个项目隶属于对应护理分类（CareCategory，如手部护理、足部护理等）。在.NET API的CareRepository中实现AddAsync方法时，最初调用CareCategoryRepository获取分类，EF Core无法跟踪变更导致护理项目无法保存；改为直接通过DbContext查询分类后，EF能正常跟踪并保存。猜测原因是不同Repository使用了不同的DbContext实例，现咨询以下哪种是最佳实践：

1. 继续当前做法，在CareRepository中直接查询分类实体
2. 将添加护理的方法移至CareCategoryRepository
3. 其他方案

当前可正常运行的代码：

public async Task<Care?> AddAsync(Care care)
{
    // var dbCareCategory = await this._careCategoryRepository.GetByNameAsync(care.CareCategoryName);
    if (string.IsNullOrEmpty(care.CareCategoryName) || string.IsNullOrWhiteSpace(care.CareCategoryName))
        return null;

    var dbCareCategory = await this._instituteDbContext.CareCategories
        .Where(careCategory => Equals(careCategory.Name, care.CareCategoryName))
        .Include(careCategory => careCategory.Cares)
        .FirstOrDefaultAsync();

    if (dbCareCategory == null || dbCareCategory.Cares.Contains(care))
        return null; // TODO : improve handling

    dbCareCategory.Cares.Add(care);

    await this._instituteDbContext.SaveChangesAsync();

    return care;
}

为什么最初的方法失效？ #

如果你的CareCategoryRepository和CareRepository注册的生命周期不一致（比如一个是瞬态，一个是范围），或者依赖注入时创建了不同的DbContext实例，那么从CareCategoryRepository获取的CareCategory实体属于另一个DbContext的跟踪上下文。当你将Care添加到这个实体的集合后，当前CareRepository的DbContext不会感知到这个变更，调用SaveChangesAsync自然不会持久化新的Care。

1. 继续当前做法 #

• 优点：代码可正常运行，逻辑集中在CareRepository，符合"添加护理项目"的业务入口直觉
• 缺点：违反单一职责原则，CareRepository直接操作了CareCategory的查询逻辑，若其他地方需要按名称查询分类，会出现代码重复；同时错误处理返回null的方式不够清晰，上层无法明确失败原因

2. 将添加护理的方法移至CareCategoryRepository #

• 核心逻辑：按照领域驱动设计（DDD）的聚合根原则，CareCategory作为包含Cares集合的聚合根，添加护理项目是聚合根的固有行为，对应的方法应该放在CareCategoryRepository中
• 示例实现：

public async Task<Care> AddCareAsync(string categoryName, Care care)
{
    if (string.IsNullOrWhiteSpace(categoryName))
        throw new ArgumentException("分类名称不能为空", nameof(categoryName));

    var dbCareCategory = await _instituteDbContext.CareCategories
        .Include(c => c.Cares)
        .FirstOrDefaultAsync(c => c.Name == categoryName);

    if (dbCareCategory == null)
        throw new KeyNotFoundException($"未找到名称为{categoryName}的护理分类");

    // 替换Contains检查：用唯一标识（如Care.Name）判断是否已存在
    if (dbCareCategory.Cares.Any(c => c.Name == care.Name))
        throw new InvalidOperationException($"分类{categoryName}下已存在名为{care.Name}的护理项目");

    dbCareCategory.Cares.Add(care);
    await _instituteDbContext.SaveChangesAsync();
    return care;
}

• 优点：职责清晰，聚合根的行为由对应的Repository管理，避免跨Repository的跟踪问题；分类查询逻辑统一在CareCategoryRepository，复用性强；错误处理改为抛出明确异常，上层可针对性处理
• 推荐度：⭐⭐⭐⭐⭐（长期维护的最佳选择）

3. 其他优化方案 #

3.1 统一DbContext生命周期 #

在ASP.NET Core中，默认DbContext是Scoped生命周期（每个请求一个实例），只要你的所有Repository都注册为Scoped，它们会自动共享同一个DbContext实例。此时最初调用CareCategoryRepository.GetByNameAsync的方法就能正常工作，因为获取的CareCategory处于同一个跟踪上下文，添加Care后SaveChangesAsync会持久化变更。

• 检查Repository的DI注册代码，确保都是services.AddScoped<ICareRepository, CareRepository>()和services.AddScoped<ICareCategoryRepository, CareCategoryRepository>()

3.2 引入工作单元（Unit of Work） #

封装DbContext为工作单元，让多个Repository共享同一个UoW实例，确保所有变更被统一跟踪和提交。示例：

public interface IUnitOfWork
{
    ICareRepository Cares { get; }
    ICareCategoryRepository CareCategories { get; }
    Task<int> SaveChangesAsync();
}

public class UnitOfWork : IUnitOfWork
{
    private readonly InstituteDbContext _dbContext;
    public ICareRepository Cares { get; }
    public ICareCategoryRepository CareCategories { get; }

    public UnitOfWork(InstituteDbContext dbContext, ICareRepository careRepo, ICareCategoryRepository careCategoryRepo)
    {
        _dbContext = dbContext;
        Cares = careRepo;
        CareCategories = careCategoryRepo;
    }

    public async Task<int> SaveChangesAsync()
    {
        return await _dbContext.SaveChangesAsync();
    }
}

• 使用时，通过UoW获取两个Repository，确保共享同一个DbContext，最后调用UoW的SaveChangesAsync提交变更

3.3 改进错误处理 #

当前代码返回null无法区分是分类不存在、分类名称为空还是护理项目已存在，建议抛出明确的自定义异常，比如：

public class CareCategoryNotFoundException : Exception { }
public class CareAlreadyExistsException : Exception { }

上层API可以捕获这些异常，返回对应的HTTP状态码（如404、409）

1. 若项目遵循DDD设计，优先选择方案2，将添加护理的逻辑移至CareCategoryRepository，符合聚合根职责，代码可维护性更强
2. 若想保留现有Repository结构，优先修复方案3.1，统一DbContext生命周期，让原本的跨Repository调用正常工作，同时优化错误处理
3. 长期来看，引入工作单元（方案3.2）可以进一步规范数据操作流程，尤其适合复杂业务场景

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