EF：将导航属性包括到在DbSet中添加实体的结果中

Question

我正在向我的DataContext添加一个实体。之后，我必须将此实体发送回视图（向最终用户显示结果）。

DbSet具有Add方法，该方法返回新实体。但是我需要包含导航属性的实体。

目前，我再次调用DataContext并传递newEntity的ID以查找该实体。

public async Task<Entity> AddAsync(Entity entity)
{
    var savedEntity = m_DataContext.Entities.Add(entity);
    await m_DataContext.SaveChangesAsync();
    return await m_DataContext.Entities
        .Include(p=>p.SubEntity)
        .FirstAsync(p=>p.Id==savedEntity.Id);
}

添加操作期间是否可以包含导航属性？

我的代码有效，但我正在寻找更优雅地实现的方法。

Answer 1

注意

我意识到这不是代码的实际解决方案。然而，这是对OP问题的一般解决方案。

另类设计理念

如果用户已输入该实体的信息，并且该信息只是被持久保存回数据库，那么您不需要将该对象发送回用户。

更好的是，如果 UI 收到成功持久化的通知，然后通过另一个请求从导航属性请求新数据。

“成功的持久化”可能只是新添加的实体的新ID。这会让你AddAsync做到的return entity.Id。在我看来，您当前实施的方法违反了 SRP AddAsync。我的例子：

public async Task<Entity> AddAsync(Entity entity)
{
    var savedEntity = m_DataContext.Entities.Add(entity);

    await m_DataContext.SaveChangesAsync();

    return entity.Id;
}

过早的优化

@CallumLinington 我是这么想的。它看起来是按照单一责任模式有机地呈现的。但我有可以查看它们的实体列表（主从模式）。此外，首先我只是将在视图上创建的实体添加到此列表中（当收到成功回调时，该实体已添加）。但它对我来说看起来并不安全。另一方面，我想限制对数据库的调用。这就是这样实现的原因

除非有真正的原因表明它不安全，而不仅仅是您的意见，并且如果有真正的原因您想限制对数据库的调用而不仅仅是您的意见，我不会限制您的设计。

在你完全证明原因之前就对自己施加不必要的限制，只会在以后产生糟糕的代码，并且你最终将不得不“破解”一些东西，因为你的设计有缺陷。

过早的优化是一种不好的做法——经过深思熟虑和合理的优化是一种好的做法。

例如，仅仅因为您认为可以节省执行速度而使用静态方法而不是实例方法是不好的。

先写最简单的方法，然后看看哪里真正需要优化。- 这几乎是 TDD 方式。