我正在使用实体框架实现DAL。每次调用方法时,我们都有一些DAL类(我称之为存储库)实例化或通过参数接收上下文。我不喜欢那种行为;我没有记录这个问题,但我的常识告诉我,上下文的实例化消耗了太多的系统资源。所以:
答案 0 :(得分:3)
我的常识告诉我,上下文的实例化消耗了太多的系统资源
在优化方面,常识几乎无用。
你认为在上下文构造函数中究竟会出现什么问题?你有read the source吗?
1)上下文的实例化是否昂贵?
相对于什么?与建立数据库连接所需的时间相比?与执行网站的DNS查找所需的时间相比?与浏览器渲染页面所花费的时间相比?
与实际通过网络检索数据所需的时间相比,上下文的实例化并不是特别耗时。
2)如果你对1回答“是”,你会如何从设计角度解决这个问题?
使用UnitOfWork abstraction。 Each UnitOfWork应该contain a single entity context。如果这是一个Web应用程序,则每个请求应该有一个UnitOfWork。
答案 1 :(得分:1)
使用ORM时,上下文生命周期管理至关重要。实体框架上下文保留有关加载实体的信息以用于延迟加载和更改跟踪目的,并且其内存占用可能会非常快速地增长。如果您不处理上下文,则基本上会出现内存泄漏。
但是,保持上下文生命周期太短是正确的,因为您可能希望使用更改跟踪。
using (var context = new DataContext())
{
context.Products.Add(product);
context.SaveChanges();
}
上面的示例显示了过快地处理上下文以利用更改跟踪功能。
对于Web应用程序,您应该根据请求使用上下文。
对于Win Form应用程序,当您从一个表单移动到另一个表单时,可以处置上下文。