是否应该在每个事务上创建 EF dbContext

我正在尝试找出管理 DbContext 的最佳方法。我见过不进行处置的代码示例，并且我见过人们说这是一个坏主意。我做下面这样的事情合适吗？另外，我应该将每个事务（包括读取）放在新的 DbContext 中吗？这可能是另一个问题，但是关于 EntityState 的部分有必要吗？

public abstract class GenericRepository<T> where T : EntityData
{
    protected MyDbContext Context
    {
        get { return new MyDbContext(); }
    }

    public T Save(T obj)
    {
        T item;
        using (var context = Context)
        {
            var set = context.Set<T>();

            if (String.IsNullOrEmpty(obj.Id))
                item = set.Add(obj);
            else
            {
                item = set.Find(obj.Id);
                item = obj;
            }

            // taken from another code sample
            var entry = context.Entry(item);
            if (entry.State == EntityState.Detached)
            {
                //Need to set modified so any detached entities are updated 
                // otherwise they won't be sent across to the db. 
                // Since it would've been outside the context, change tracking 
                //wouldn't have occurred anyways so we have no idea about its state - save it!
                set.Attach(item);
                context.Entry(item).State = EntityState.Modified;
            }
            context.SaveChanges();
        }

        return item;
    }
}

EDIT
我还有一个扩展类来实现下面的这个功能。上下文没有包含在该查询中的 using 语句中，因此我对我的代码有点怀疑。

public IQueryable<T> FindByAccountId(string accountId)
{
    return from item in Context.Set<T>()
        let user = UserRepository.FindByAccountId(accountId).FirstOrDefault() 
        where item.UserId == user.Id
        select item;
}

上下文实际上应该基于每个请求。请求到来并创建一个新的上下文。该上下文用于请求的其余部分，然后在请求结束时相应地进行处理。这为您带来了请求长事务的好处，并且正如 HamidP 所强调的那样，您还可以获得缓存实体的额外好处；这意味着加载到上下文中的任何实体都可以通过检索来加载，而无需实体框架查询数据库。

如果您使用任何类型的控制反转容器（例如 StructureMap），那么您可以通过以下配置轻松创建 HTTP 请求绑定上下文：

this.For<DbContext>().HybridHttpOrThreadLocalScoped().Use<DbContext>();

然后你就可以注入你的DbContext（或其衍生物）到您的存储库中，并保留您选择的 IOC 容器以在请求结束时处理上下文。如果您要将相同的上下文注入另一个存储库，那么您将收到相同的上下文实例。

我希望这有帮助！