HttpApplication会不断处理ASP.NET分发给他的HTTP请求,在不同的时刻会触发不同的事件,我们可以将特定的处理程序注册到指定事件上,从而使的ASP.NET在特定时刻执行我们的业务逻辑。这就是管道的基本原理。
在以往的代码中,为了避免互相干扰,我使用的是傻瓜式的EF生命周期管理,其代码类似这样:
/// <summary>
/// 获得一个实体的投影
/// </summary>
/// <param name="exp">筛选委托</param>
/// <param name="selector">投影委托</param>
/// <returns>dynamic</returns>
public static dynamic GetPartEntity(Func<T, bool> exp, Func<T, dynamic> selector)
{
using (var db = new CapitalConstructionEntities())
{
return db.Set<T>().Where(exp).Select(selector).SingleOrDefault();
}
}
而在客户端代码中,当某一个方法体内需要执行多次查询时,需要多次创建EF数据库上下文对象。DBContext这种复杂的大对象创建是非常耗时的,因为背后包含与数据库相关的非托管代码。虽然这种处理方式在小吞吐量系统中性能下降并不明显,但的确不是一种好的方式。比如下面这段代码,在一个方法内多次创建了EF上下文,造成了性能浪费:
//保存修改
public string SaveChanges(int id,string type)
{
Project modify = ProjectDao.GetEntity(p => p.Project_ID== id);
modify.Project_Type = Trans.FCBS(type);
if (ProjectDao.Update(modify))
{
return JsonConvert.SerializeObject(new { Success = true, Message = "修改成功!" });
}
else
{
return JsonConvert.SerializeObject(new { Success = false, Message = "修改失败!" });
}
}
最近看了和尚兄的代码,原来数据库上下文也可以在管道事件中实例化与销毁,在单次请求中共享一个实例,性能可以提高不少。分别在开始请求和结束请求事件中创建和析构了数据库上下文对象:
class DBModule : IHttpModule
{
public void Dispose() { }
public void Init(HttpApplication context)
{
context.BeginRequest += new EventHandler(
(object sender, EventArgs e) =>
{
context.Context.Items.Add("db", new DBContainer());
});
context.EndRequest += new EventHandler(
(object sender, EventArgs e) =>
{
var db = context.Context.Items["db"];
if (db != null)
{
(db as DBContainer).Dispose();
}
});
}
}
这样一来,在一次请求中只需要实例化一次EF数据库上下文对象即可。
因篇幅问题不能全部显示,请点此查看更多更全内容