我不知道是否有更好的方法来使用,DbContext
因为在使用 WCF 时不建议将其设置为静态。所以我们每次想要访问数据库时都会创建它。
了解了使用 Entity Framework 的所有优点,有些变得无用,因为我们DbContext
每次都在重新创建;并且更多可能会导致开销,因为要考虑创建大实体模型的过程。
你有什么意见?
我不知道是否有更好的方法来使用,DbContext
因为在使用 WCF 时不建议将其设置为静态。所以我们每次想要访问数据库时都会创建它。
了解了使用 Entity Framework 的所有优点,有些变得无用,因为我们DbContext
每次都在重新创建;并且更多可能会导致开销,因为要考虑创建大实体模型的过程。
你有什么意见?
您是正确的,通常DbContext
不建议使用单个静态实例:
您使用 ObjectContext 的次数越多,它通常就越大。这是因为它包含对它所知道的所有实体的引用,基本上是您查询、添加或附加的任何内容。所以你应该重新考虑无限期地共享同一个 ObjectContext。
这些注释直接适用于DbContext
,因为它封装了 wrapsObjectContext
以公开“简化和更直观的 API”。 [见文档]
创建上下文的开销相对较低:
现实情况是这个成本实际上相当低,因为它主要涉及通过引用将元数据从全局缓存复制到新的 ObjectContext 中。一般来说,我认为这个成本不值得担心......
使用短期上下文的常用方法是将其包装在 using 块中:
using(DbContext context = new SomeDbContext())
{
// Do work with context
}
为了简化测试,您可能希望DbContext
实现一些IDbContext
接口,并创建一个工厂类ContextFactory<T> where T : IDbContext
来实例化上下文。
这使您可以轻松地将任何内容交换IDbContext
到您的代码中(即对象模拟的内存上下文。)
Web 开发的最佳实践似乎是“每个 Web 请求一个上下文”,请参阅Proper Session/DbContext 生命周期管理,当使用 WCF 时,这可以转换为每个操作一个上下文(即每个 WCF 方法调用一个上下文)。
有不同的方法可以实现这一点,但一种可能由于不同原因不推荐的解决方案是创建上下文的新实例并将其传递给业务类的构造函数:
public void WCFMethod()
{
using (DBContext db = new DBContext())
{
BusinessLogic logic = new BusinessLogic(db);
logic.DoWork();
}
}