LINQ-to-SQL虽然已经属于过去事了，但由于历史原因，还是要关注一下它，呵呵，当微软推出linq to sql之后，最吸引开发者的地方可能就是可视化的数据模型，灵活可控的分部方法及神神秘秘的延时加载了，呵呵！今天主要再总结一个linq to sql中的延时加载！

对于数据上下文DataContext来说，它有一个属性叫做DeferredLoadingEnabled，它的默认值为true，意思是开启模型的延时加载功能，例如：当你有一个对象Order_info，它有关系表Order_Detail,它们之间为一对多的关系，这在dbml模型中用EntitySet<T>来表示，意为实体的集合。而开启模型的延时加载功能时，只要你查询出Order_Info后，如果在前台使用到了Order_Detail，系统就会将Order_Detail的相关数据也查询出来，听上去不错，看代码：

@foreach (var item in Model)
{ 
    <p>
        @item.OrderID
        @item.CreateDate
    </p>
   if (item.Order_Detail.Count > 0)
   {
       foreach (var detail in item.Order_Detail)
       { 
    <p style="margin: 10px;">@detail.OrderID @detail.ProductName</p>
       }
   }
}

产生的ＳＱＬ代码：

注意，当前台对Order_Detail有需要时，系统会产生查询Order_Detail的代码，如果你的１０条Order_Info记录，那么，系统会向SQLSERVER发送１０条语句
，这让我们感觉到了一点坏味道，没错，使用延时加载不但没有提高性能，反尔加大了数据库的交互，事实上，我可能不是微软的本意，可能是我们误会了DeferredLoadingEnabled的用意，呵呵！

DeferredLoadingEnabled使用场合：对于单条记录可以使用，对于集合对象不应该使用它

Linq To Sql对于集合对象的导航属性进行延时加载，提供了自己的解决方案

小插曲，一般我们建立ＤＢＭＬ模型后，如果希望改它的代码部分我们一般不会在原文件上改，因为重新生成数据模型后，你改的代码就被覆盖了，而我们的做法是新建一个类文件，它与ＤＢＭＬ模型文件的数据上下文对象同名（微软为我们建立的上下文类是partial的，人家已经为咱们预留出接口了，呵呵），如果希望在数据上下文被建立时执行代码，可以在分部方法OnCreate里作文章（注意默认构造方法已经被原类占用，所以你的分部类不能再定义一个空构造方法了，呵呵）。

DataLoadOptions 对象为我们提供了立即加载模式，它所产生的ＳＱＬ语句是我们可以接受的，但它不会按需查询了，即将order_info和order_detail进行join

查询并直接返回数据，呵呵。

这种方法只在分部方法OnCreate中定义即可，你的ＤＡＬ实现层，ＢＬＬ业务组合层，ＷＥＢ展现层的代码都不用调整，呵呵。

　　　　 partial void OnCreated()
        {
            // this.DeferredLoadingEnabled = false;//关闭延时加载
            #region 优化后的延时加载，对某个对象进行延时加载
            DataLoadOptions dl = new DataLoadOptions();
            dl.LoadWith<Order_Info>(p => p.Order_Detail);
            this.LoadOptions = dl;
            #endregion

        }

而这种立即加载所产生的ＳＱＬ语句是我们可以接受的，看图：

它解释成的ＳＱＬ语句也是我们熟悉的，看代码：

SELECT [t0].[OrderID], [t0].[UserID], [t0].[CreateDate], [t1].[OrderDetailID], [t1].[OrderID] AS [OrderID2], [t1].[ProductID], [t1].[ProductName], (
    SELECT COUNT(*)
    FROM [dbo].[Order_Detail] AS [t2]
    WHERE [t2].[OrderID] = [t0].[OrderID]
    ) AS [value]
FROM [dbo].[Order_Info] AS [t0]
LEFT OUTER JOIN [dbo].[Order_Detail] AS [t1] ON [t1].[OrderID] = [t0].[OrderID]
ORDER BY [t0].[OrderID], [t1].[OrderDetailID]

恩，看来linq to sql知所以性能低下，不是它本身的问题，而是我们对它不够了解呀，呵呵！

相关文章：EF架构~对不起Include，是我冤枉你了！

本文转自博客园张占岭（仓储大叔）的博客，原文链接：LINQ-to-SQL那点事~关于延时加载的性能，微软给出了不错的解决方案，如需转载请自行联系原博主。