代码之家 › 专栏 › 技术社区 › Mark Carpenter

可重用的ObjectContext还是每一组操作的新ObjectContext?

objectcontext data-access-layer linq-to-entities c#

3

Mark Carpenter · 技术社区 · 15 年前

我对实体框架还不熟悉,只是在业余时间开始玩弄它。我的主要问题之一是如何处理对象上下文。

这通常是首选/推荐的:

这个

public class DataAccess{

    MyDbContext m_Context;

    public DataAccess(){
        m_Context = new MyDbContext();        
    }

    public IEnumerable<SomeItem> GetSomeItems(){
        return m_Context.SomeItems;
    }

    public void DeleteSomeItem(SomeItem item){
        m_Context.DeleteObject(item);
        m_Context.SaveChanges();
    }
}

或者这个?

public class DataAccess{

    public DataAccess(){ }

    public IEnumerable<SomeItem> GetSomeItems(){
        MyDbContext context = new DbContext();
        return context.SomeItems;
    }

    public void DeleteSomeItem(SomeItem item){
        MyDbContext context = new DbContext();
        context.DeleteObject(item);
        context.SaveChanges();
    }
}

4 回复 | 直到 15 年前

1

6

Orion Edwards 15 年前

ObjectContext是指“工作单元”。

本质上,这意味着对于每个“操作”(例如:每个网页请求),都应该有一个新的ObjectContext实例。在该操作中,应重新使用相同的ObjectContext。

当您考虑它时,这是有意义的,因为事务和变更提交都与ObjectContext实例相关联。

如果您不是在编写Web应用程序,而是在编写WPF或Windows窗体应用程序,它会变得更加复杂,因为您没有Web页面加载给您的严格“请求”范围,但是您得到了这个想法。

ps:在您的任一示例中,objectcontext的生存期要么是全局的,要么是暂时的。在这两种情况下,它不应该存在于dataaccess类中-它应该作为依赖项传入

2

1

Stéphane 15 年前

如果您保持相同的上下文 长期运行 进程运行 大量查询 与之相反,linq to sql(我没有对linq to实体进行测试,但我想这是同一个问题)的速度非常慢(大约1000个简单查询之后,每秒1个查询)。定期更新上下文可以解决这个问题,而且成本也不高。

结果是上下文会跟踪你对它所做的每一个查询,所以如果不以某种方式重置它,它会变得很胖…另一个问题是它需要的内存。

因此,这主要取决于应用程序的工作方式,以及您是否定期新建一个数据访问实例,或者是否一直保持不变。希望这有帮助。

斯塔芬

3

0

xximjasonxx 15 年前

只是一个简短的说明——这两个代码片段在其基础问题上大致相同。这是我一直在关注的问题,因为您不想一直打开和关闭上下文(参见第二个示例),同时您不确定是否可以信任Microsoft为您正确地处理上下文。

我所做的一件事是创建一个普通的基类,它懒惰地将上下文加载到中,并实现基类析构函数来处理事情。这对于类似MVC框架的东西很有效,但不幸的是,这导致了必须将上下文传递到各个层,以便业务对象可以共享调用的问题。

最后,我使用ninject将这个依赖项注入到每个层,并让它跟踪使用情况。

4

0

Andras Zoltan 15 年前

虽然我不赞成每次需要复杂的对象时总是创建它们,但我也发现Linq to SQL中的数据上下文和EF中的对象上下文在需要时是最好的。

这两种方法都基于运行它们所使用的模型执行了大量静态初始化,这些模型被缓存用于后续调用,因此您会发现上下文的初始启动时间比所有后续实例化时间都长。

您面临的最大障碍是,一旦您从上下文中获取了一个实体,就不能简单地将其传递回另一个实体来执行更新操作,或将相关实体添加回。在EF中,可以将实体重新附加回新的上下文。在L2S中,这个过程几乎是不可能的。