从 LINQ to SQL 升级到 EF 4.1 时，如何最大限度地减少性能损失？

我最近将一个使用 LINQ to SQL 和 SQL Server CE 3.5 的应用程序更新为 Entity Framework 4.1 Code First 和 SQL Server CE 4.0，现在它的运行速度明显变慢。我在之前和之后做了一些秒表测试，我的应用程序的大多数主要操作似乎平均运行速度慢了 40% 左右。

除了禁用级联删除之外，我正在使用 EF Code First 的所有默认策略和配置。

当我最初发布这个问题时，我关注的是一个似乎花费特别长的查询，但我后来意识到它只是在第一次运行时特别慢（请参阅下面的评论线程）。

我现在认为我看到的是大多数查询运行速度变慢 - 不是显着变慢，而是慢到足以快速累加，因为应用程序执行的大多数操作都涉及多个查询。

这个应用程序有一个非常小的数据库。 SQL CE (.sdf) 文件只有 458 KB，最大的表只有不到 250 条记录。

下面是 POCO 类的示例：

public class Target
{
    public int Id { get; set; }
    public int TrialDefinitionId { get; set; }
    public int Number { get; set; }
    public int X { get; set; }
    public int Y { get; set; }
    public string Phase { get; set; }
    public virtual TrialDefinition TrialDefinition { get; set; }
}

我的所有类都遵循这个基本模式（简单类型+虚拟属性来获取通过外键链接的对象）。我有一个类使用ICollection获取多对一关系的列表。

最后一点：我使用存储库模式作为中介，并且存储库的每次使用都放在using堵塞。对于“获取”操作，一旦我从数据库获取了所需的数据，这就会导致实体分离。

有人有任何具体策略来提高我的 EF Code First 应用程序的性能吗？请记住，我还没有机会详细阅读 EF。我主要只是尝试尽可能快速、轻松地从 LINQ to SQL 迁移到 EF。对我来说最有用的答案是更改特定策略或配置或其他设置。

最后注意事项：我使用存储库模式作为中介，并且存储库的每次使用都放置在 using 块中。对于“获取”操作，一旦我从数据库获取了所需的数据，这就会导致实体分离。

嗯，这不是必需的...

1. 实体框架的默认架构已经实现了存储库模式。
2. 保持 ObjectContext 处于活动状态并不意味着您保持与数据库的连接处于活动状态。
3. 仅当您从数据库加载或保存更改时，才会从连接池中获取新连接并执行操作。

当然，使用块会减慢，因为每个使用块都会执行以下操作，

1. 初始化上下文（需要从资源加载元数据）
2. 验证一些事情
3. 打开与数据库的连接
4. 执行你的任务
5. 清理并关闭数据库

现在，前两个步骤肯定会花费大量时间，并且您的应用程序中将有多个相同类型的对象寿命更长，因为每个新上下文都会为每个查询创建相同对象的新副本。

实体框架已经实现了身份映射，这意味着它将在上下文的整个生命周期中保持对象处于活动状态，并且同一主键仅保留一份对象副本，这不仅可以节省内存，而且可以更快地执行。

我建议不要对每个查询或较小的步骤使用“使用块”，而是应该在应用程序的整个生命周期中保持 ObjectContext 处于活动状态。而且您根本不需要实现缓存或存储库。