Warning: file_get_contents(/data/phpspider/zhask/data//catemap/0/performance/5.json): failed to open stream: No such file or directory in /data/phpspider/zhask/libs/function.php on line 167

Warning: Invalid argument supplied for foreach() in /data/phpspider/zhask/libs/tag.function.php on line 1116

Notice: Undefined index: in /data/phpspider/zhask/libs/function.php on line 180

Warning: array_chunk() expects parameter 1 to be array, null given in /data/phpspider/zhask/libs/function.php on line 181
Performance 实体框架和ObjectContext n层体系结构_Performance_Linq_Entity Framework_Entity Framework 4_Linq To Entities - Fatal编程技术网

Performance 实体框架和ObjectContext n层体系结构

Performance 实体框架和ObjectContext n层体系结构,performance,linq,entity-framework,entity-framework-4,linq-to-entities,Performance,Linq,Entity Framework,Entity Framework 4,Linq To Entities,我有一个基于非常经典的不同层的n层应用程序:用户界面、服务(WCF)、业务逻辑和数据访问 数据库(Sql Server)显然是通过实体框架进行查询的,问题基本上是每个调用都从用户界面开始,并通过所有层,但要做到这一点,我每次都需要为每个操作创建一个新的ObjectContext,这使得性能非常糟糕,因为每次我都需要重新加载元数据并重新编译查询 建议最多的模式是下面的模式,这就是我实际正在做的:每次服务接收到调用时,通过业务层方法创建和传递新的上下文 public BusinessObject

我有一个基于非常经典的不同层的n层应用程序:用户界面、服务(WCF)、业务逻辑和数据访问

数据库(Sql Server)显然是通过实体框架进行查询的,问题基本上是每个调用都从用户界面开始,并通过所有层,但要做到这一点,我每次都需要为每个操作创建一个新的ObjectContext,这使得性能非常糟糕,因为每次我都需要重新加载元数据并重新编译查询

建议最多的模式是下面的模式,这就是我实际正在做的:每次服务接收到调用时,通过业务层方法创建和传递新的上下文

 public BusinessObject GetQuery(){     
   using (MyObjectContext context = new MyObjectContext()){ 
      //..do something  }    }
对于简单的查询,我看不到任何特定的dealy,它工作得很好,但对于复杂和繁重的查询,它会进行2秒的查询,每次调用大约15秒

我可以将ObjectContext设置为静态,这样可以解决性能问题,但似乎没有人建议这样做,这也是因为我无法同时从不同的线程访问上下文,并且多个调用会引发异常。我可以使它线程安全,但长时间保持相同的ObjectContext会使它越来越大(越来越慢),因为它导入每个查询的引用会执行一个查询

我认为它是最常见的体系结构,那么什么是实现和使用ObjectContext的最好和已知的方法呢

谢谢,,
Marco

在Web上下文中,最好使用无状态方法,为每个请求创建一个
ObjectContext

ObjectContext
构建的成本是最低的。元数据是从全局缓存加载的,因此只有第一个调用需要加载元数据

静态绝对不是一个好主意。
ObjectContext
不是线程保存,这将导致在具有多个调用的WCF服务中使用它时出现问题。使其线程保存将导致性能降低,并且在多个请求中重用它时可能会导致细微错误


检查此信息:

在Web上下文中,最好使用无状态方法并为每个请求创建一个
ObjectContext

ObjectContext
构建的成本是最低的。元数据是从全局缓存加载的,因此只有第一个调用需要加载元数据

静态绝对不是一个好主意。
ObjectContext
不是线程保存,这将导致在具有多个调用的WCF服务中使用它时出现问题。使其线程保存将导致性能降低,并且在多个请求中重用它时可能会导致细微错误


检查此信息:

您显示的是使用按请求上下文的典型模式,类似于使用数据库连接

是什么让您认为糟糕的性能与重新创建上下文有关?很可能不是这样。你是如何衡量这种影响的


如果您有这样的性能关键代码,以至于这种开销确实很重要,那么您不应该使用实体框架,因为总是会有一些开销,即使在一般情况下开销应该很小。不过,我将开始关注您的数据模型和底层数据存储,它们将对您的查询性能产生更大的影响。您优化了您的查询了吗?你把索引放在你需要的地方了吗?是否可以对数据进行反规范化以删除联接

您展示的是使用按请求上下文的典型模式,类似于使用数据库连接

是什么让您认为糟糕的性能与重新创建上下文有关?很可能不是这样。你是如何衡量这种影响的


如果您有这样的性能关键代码,以至于这种开销确实很重要,那么您不应该使用实体框架,因为总是会有一些开销,即使在一般情况下开销应该很小。不过,我将开始关注您的数据模型和底层数据存储,它们将对您的查询性能产生更大的影响。您优化了您的查询了吗?你把索引放在你需要的地方了吗?是否可以对数据进行反规范化以删除联接

使用静态对象上下文不是一个好主意。静态上下文将由web应用程序的所有用户共享,这意味着当一个用户对上下文进行修改(如调用saveChanges)时,使用该上下文的所有其他用户都将受到影响(如果假设他们已向上下文添加或更新数据,但未调用save changes,这将是一个问题)。使用对象上下文时的最佳实践是在请求期间保持其活动状态,并使用if执行任何原子业务操作。您可能想查看UnitOfWork模式和repository模式

如果您觉得查询存在性能问题,并且可能会重用查询,我建议您使用预编译的linq查询。你可以查看下面的链接了解更多信息


使用静态对象上下文不是一个好主意。静态上下文将由web应用程序的所有用户共享,这意味着当一个用户对上下文进行修改(如调用saveChanges)时,使用该上下文的所有其他用户都将受到影响(如果假设他们已向上下文添加或更新数据,但未调用save changes,这将是一个问题)。使用对象上下文时的最佳实践是在请求期间保持其活动状态,并使用if执行任何原子业务操作。您可能想查看UnitOfWork模式和repository模式

如果您觉得查询存在性能问题,并且可能会重用查询,我建议您使用预编译的linq查询。你