字段成员与方法变量？

Question

最近我一直在考虑类字段成员和方法变量之间的性能差异.我的意思是在下面的例子中:

可以说我们有一个Linq2SQL的DataContext对象

class DataLayer
{
    ProductDataContext context = new ProductDataContext();

    public IQueryable<Product> GetData()
    {
       return context.Where(t=>t.ProductId == 2);
    }
}

在上面的示例中,上下文将存储在堆中,GetData方法执行后,方法变量将从Stack中删除.

因此,让我们检查以下示例以区分:

class DataLayer
{
    public IQueryable<Product> GetData()
    {
       ProductDataContext context = new ProductDataContext();
       return context.Where(t=>t.ProductId == 2);
    }
} 

(*1)首先我们知道的是,如果我们将ProductDataContext实例定义为一个字段,我们可以在类中的任何地方到达它,这意味着我们不必一直创建相同的对象实例.

但是让我们说我们正在讨论Asp.NET,一旦用户按下提交按钮,就会将发布的数据发送到服务器并执行事件,并通过上述方法将发布的数据存储在数据库中,这样很可能是同一个用户可以发送不同的数据后的一个another.If我正确认识执行页面后,将终结发挥作用,从内存中清除的事情(从堆),这意味着我们失去了我们的实例变量从内存中以及之后另一篇文章中,DataContext应为新页面循环再次创建.

因此,向全班公开宣布它的唯一好处就是上面的第一个文字.

或者还有其他什么？

提前致谢...

(如果我说错了,请修理我..)

Answer 1

当谈到每个方法或每个类实例创建一个对象之间的性能差异时,我不会太担心它.但是,您似乎在这里想到的是一般围绕DataContext类和工作单元模式的一些重要原则.

DataContext类作为单个工作单元运行.因此,您创建DataContext,创建对象,更新和删除对象,提交所有更改,然后在此之后释放DataContext.您可以为每个请求创建多个DataContext类,每个(业务)事务一个.但是在ASP.NET中,您永远不应该创建一个在Web请求中幸存的DataContext.请求期间或之前应处理请求期间创建的所有DataContexts.有两个原因.

首先,DataContext具有从数据库中提取的所有对象的内部缓存.长时间使用DataContext将使其缓存无限增长,并且当您拥有一个大型数据库时可能会导致内存问题.DataContext还支持在缓存中从缓存中返回对象,使您的对象快速失效.由于这种陈旧性,任何对另一个DataContext或直接对数据库进行的更新和删除操作都会被忽视.

不缓存DataContexts的第二个原因是它们不是线程安全的.最好将DataContext视为工作单元或(业务)事务.您创建了一堆新对象,将它们添加到DataContext,更改其他对象,删除一些对象,完成后,您调用SubmitChanges.如果另一个请求在该操作期间在同一个实例上调用SubmitChanges,则您将失去该事务的想法.当您允许代码执行此操作时,在最幸运的情况下,您的新对象将被保留,并且您的事务将在两个单独的事务中拆分.在最坏的情况下,您将DataContext或其持久的对象保留为无效状态,这可能意味着其他请求失败或无效数据进入您的数据库.这不是一个不可能的场景,我看到项目发生了奇怪的事情,开发人员为每个网站创建了一个(静态)DataContext.

所以考虑到这一点,让我们回到你的问题.虽然将DataContext定义为实例字段不是问题,但了解如何使用DataLayer该类非常重要.当您DataLayer为每个请求或每个方法调用创建一个时,您可能是安全的,但在这种情况下,您不应将其存储DataLayer在静态字段中.如果要这样做,则应该为每个方法调用创建一个DataContext.

重要的是要知道DataLayer班级的设计是什么.在您的代码中,您只向我们展示了一种查询方法.没有CUD方法.是每个方法都是单个事务,还是要调用多个方法并在DataLayer之后调用SaveChanges ？当你想这个最后的选择,你需要存储DataContext的实例字段和你应该实现这种情况下IDisposable的DataLayer.当每个方法都是自己的事务时,您可以为每个方法创建一个DataContext,并且应该将一个DataContext包装在using语句中.但请注意,从方法返回具有延迟加载属性的对象时,处理DataContext可能会导致问题.处理DataContext时,无法再加载这些属性.这里有更多有趣的信息.

如您所见,我甚至没有谈到您的两个选项中哪一个对性能更好,因为当解决方案给出不一致和不正确的结果时,性能并不重要.

对不起,我很抱歉:-)