使用实体框架实现 DAL 时增强其性能

Question

我正在使用实体框架实现 DAL。我们有一些 DAL 类（我称之为存储库），每次调用方法时都会通过参数实例化或接收上下文。我不喜欢这种行为；我没有关于这个问题的记录，但我的常识告诉我，上下文的实例化消耗了太多的系统资源。那么：

1. 上下文的实例化成本昂贵吗？
2. 如果您对 1 的回答是“是”，您将如何从设计角度解决这个问题？
3. 如果您对 1 的回答是“是”，您将如何在 C# 中实现该解决方案？
4. 您建议采用哪种方法来为 Web 应用程序实现 DAL？

Answer 1

我的常识告诉我，上下文的实例化消耗了太多的系统资源

。在优化方面，常识几乎毫无用处。

您认为上下文的构造函数中究竟会出现什么问题？您阅读源代码了吗？

1）上下文的实例化开销大吗？

相对于什么？与建立数据库连接所需的时间相比？与执行站点 DNS 查找所需的时间相比？与浏览器渲染页面所花费的时间相比？

最有可能的是，与通过网络实际检索数据所需的时间相比，上下文的实例化并不是特别耗时。

2) 如果您对 1 的回答是“是”，您将如何从设计角度解决这个问题？

使用 UnitOfWork 抽象。 每个工作单元< /a> 应该包含单个实体上下文。如果这是一个网络应用程序，则每个请求应该有一个工作单元。

Answer 2

使用 ORM 时，上下文生命周期管理至关重要。实体框架上下文保留有关已加载实体的信息以用于延迟加载和更改跟踪目的，并且其内存占用量可能会快速增长。如果你不处理你的上下文，你基本上就会发生内存泄漏。

但是，您是正确的，将上下文生命周期保持得太短并不理想，因为您可能希望利用更改跟踪。

using (var context = new DataContext())
{
    context.Products.Add(product);
    context.SaveChanges();
}

上面的示例显示，处理上下文的速度太快，无法利用更改跟踪功能。

对于 Web 应用程序，您应该为每个请求使用上下文。

对于 Win Form 应用程序，当您从一种窗体移动到另一种窗体时，您可以处理上下文。