我总是尝试防止将LINQ to sql DataContext泄漏到表示层(您的Web应用程序)中.所以它不应该能够创建或提交DataContext.您也不应该返回IQueryable< T>对象到表示层. IMO的业务层应该完全控制DataContext(工作单位)的生命周期以及SQL查询的形状.

但是,有几种口味.有些人冒充放松这些限制.其他人甚至更进一步.这取决于你自己的口味和应用程序的大小.应用程序越大,添加抽象层就越有道理.

当不允许IQueryable和其他数据相关的东西离开业务层时,您最终会遇到一些有趣的挑战.例如,表示层必须指示业务层如何对结果进行排序.虽然您可以让表示层对结果进行排序,但这意味着您必须从表单层的数据库和页面获取所有数据,导致性能非常差的系统.这个问题有几种解决方案.在所有情况下,您都需要通知业务层如何为您排序结果.在搜索LINQ dynamic sort时,SO可以找到解决方案.我自己写了这样一个解决方案,here.

不允许IQueryable离开你的BL的另一个挑战将是域对象经常不会离开你的BL.大多数LINQ to sql域对象将包含延迟加载的属性(例如,到其他域对象的集合).但是,当DataContext控制业务层时,在将结果返回到表示层之前,将会被处理.当演示文稿比访问延迟加载的属性时,会发生异常,因为DataContext已被处理.当您将DataContext处理在业务层中时,此行为当然是“按设计”.允许表示层获取延迟加载属性意味着BL将丢失对发送到数据库的查询的控制,从而失去对性能的控制.

要解决此问题,您应该将数据传输对象(DTO)从BL返回到表示层. DTO将只包含数据,没有内部的DataContext,并且没有延迟加载的属性. DTO可以根据实际的要求进行特殊格式化. DTO当然会导致编码开销本身,所以您的系统的大小和性能需求必须证明它.为了使自己更容易,我倾向于在DTO上放置静态投影方法.虽然这不符合separation of concerns原则,但我认为这是一个非常实用的解决方案.在这个客户端看例子：

public class CustomerDTO
{
    public int CustomerId { get; set; }
    public string Name { get; set; }
    // City is flatterned from Address.City.
    public string City { get; set; }

    internal static IQueryable<CustomerDTO> AsDTO(IQueryable<Customer> customers)
    {
        return
            from customer in customers
            select new CustomerDTO()
            {
                CustomerId = customer.Id,Name = customer.Name,City = customer.Address.City
            };
    }
}

该DTO定义了内部AsDTO方法,该方法能够将Customer域对象的集合转换为CustomerDTO DTO的集合.这使得将域对象转换为DTO变得更加容易.以这种BL方法为例：

public static CustomerDTO[] GetCustomersByCountry(string country)
{
    using (var db = ContextFactory.CreateContext())
    {
        IQueryable<Customer> customers =
            (from customer in db.Customers
            where customer.Address.Country == country
            orderby customer.Name,customer.Id);

        return CustomerDTO.AsDTO(customers).ToArray();
    }
}

这种方法的好处是,当您查看SQL查询时,您将看到只有客户ID,名称和地址表的城市将从数据库中检索.这是因为AsDTO方法将一个IQueryable转换为另一个,允许LINQ to sql在数据库中执行总体操作.

我希望这能给出一些你能做什么的想法.当然,这是我对这个问题的看法,以及我在我的情况下发现的实际情况.