处置的真实用法是什么? 这是第一个(我的)方法:
public class RequestService : IDisposable
{
requestDBEntities db;
public RequestService() //Constructor
{
db = new requestDBEntities ();
}
public List<RequestStatus> ddlFill()
{
return (from rs in db.reqStatus select rs).ToList();
}
//Some Insert,Update,Delete methods {}...
public void Dispose()
{
db.Dispose(); //<--Dispose requestDBEntities();
GC.SuppressFinalize(this);
}
第二种方法:
public class RequestService : IDisposable
{
requestDBEntities db;
public List<RequestStatus> ddlFill()
{
using (db = new requestDBEntities())
return (from rs in db.reqStatus select rs).ToList();
}
//Some Insert,Update,Delete methods {}...
public void Dispose()
{
GC.SuppressFinalize(this);
}
Page Code-behind:
using (RequestService _reqService = new RequestService ())
{
ddlRequestStatus.DataSource = _reqService.ddlFill();
ddlRequestStatus.DataBind();
//Some Insert,Update,Delete operations...
}
谢谢..
答案 0 :(得分:0)
很难(不可能)说出哪种方法更好,因为我们不知道您的确切设计选择。从一个简单的应用程序的角度来看,似乎这两个例子是等价的(或多或少),但它们确实表现得完全不同。
这里的基本问题是:db
的生命周期应该与其封闭的RequestService
实例的生命周期相比吗?
如果是,那么第一个代码示例就是做事的方式。资源将按预期进行管理(db
在要求RequestService
对象处理其资源的同时处理其内容,并且两者的生命周期几乎相同({{1}在db
构造函数中构造,RequestService
一旦db
对象变为可收集,就变为可收集。
但是,如果答案是“否”,那么第二个例子(几乎)是做事的方式 - 因为你从RequestService
生成RequestStatus
对象的集合视图,你真的我没有理由再保持db
。但是,为了更好一些,我建议将db
的范围限制在db
方法中:
ddlFill
当堆栈值足够时,不需要无关的类成员。
答案 1 :(得分:0)
在第二个示例中,您声明了requestDBEntities db;在类级别而不是将其作为堆栈变量?
比较您的方法,问题是 - 您准备好在每次通话时创建requestDBEntities吗?如果你是 - 第二种方法更好,事实上如果没有其他你没有发布 - 你根本不需要处置。但是,在每次调用时实例化/释放requestDBEntities都会有额外的时间损失。