1、LINQ to SQL集成到应用程序中需考虑的一个问题, 到底应该返回IQueryable<T>还是IQueryable? 或许这个列表还应该继续扩展为T, List<T>, 对于Business Layer来说, 到底应该选择哪一种?
2、需要一个分页功能; 到这一步的时候我又有几个选择, 利用LINQ to SQL可以执行自定义存储过程的功能, 完全自己写, LINQ to SQL本身已经有API提供了分页功能了,不过只有排序或包含标识列的查询中支持Skip方法, 我有什么理由放弃, 除非性能真的到了非常Critical的时候, 看看下面的分页API, 多么简单:
return q.Skip<Order>((currentPage - 1) * pageSize).Take< Order >(pageSize)
生成的T-SQL语句:
SELECT [t2].[OrderID], [t2].[OrderNumber], [t2].[OrderName], [t2].[DateSubmitted], [t2].[SubmittedBy], ([t2].[LastName] + @p2) + [t2].[FirstName] AS [SubmittedUserName]
FROM (
SELECT TOP (10) [t0].[OrderID], [t0].[OrderNumber], [t0].[OrderName], [t0].[SubmittedBy], [t0].[DateSubmitted], [t1].[FirstName], [t1].[LastName]
FROM [dbo].[Order] AS [t0]
INNER JOIN [dbo].[Users] AS [t1] ON [t1].[UserID] = [t0].[SubmittedBy]
WHERE ([t0].[NextProcessedBy] = @p0) AND ([t0].[CurrentState] = @p1)
) AS [t2]
– @p0: Input NVarChar (Size = 3; Prec = 0; Scale = 0) [jlv]
– @p1: Input NVarChar (Size = 3; Prec = 0; Scale = 0) [New]
– @p2: Input NVarChar (Size = 2; Prec = 0; Scale = 0) [, ]
DLINQ生成的SQL语句是利用TOP和嵌套子查询, 这种方法已经被证明是比较高效的做法(相比于临时表的做法), 所以完全有理由可以一试.到这里, List, IQueryable, IQueryable都没有任何问题.
3、需要一个动态排序功能, 这里List的局限性出来了, 传统的做法可能需要用一个dynamic参数来传递需要排序的列然后到SP当中来执行, 但我们已经不打算使用SP了, 也没有动态sql语句, 所有的东西都是强类型的, 然后有LINQ to SQL在运行时来帮我们转换为T-SQL语句。首先List的话, 我们不知道到底哪个字段要排序, 如果使用字符串作为参数的话, 例如放一个string sortBy作为方法的参数, 那么在方法体内就需要做if…else或者switch的判断, 而且还要考虑倒序还是正序的排序要求, 而且你还要hard code,很明显麻烦来了.然而如果使用IQueryable却可以很好的解决所有的这些问题. 但是IQueryable不能跨assembly, 一旦跨了assembly的话, 你无法使用var来引用匿名类里面的property, 绑定到control是没有问题的, 但是客户端的动态查询却成了问题, 因为你根本不知道匿名类是什么. 那么选择IQueryable<T>, 我们选择返回IQueryable<T>给客户端, 分页/排序都没有任何问题.
2、需要一个分页功能; 到这一步的时候我又有几个选择, 利用LINQ to SQL可以执行自定义存储过程的功能, 完全自己写, LINQ to SQL本身已经有API提供了分页功能了,不过只有排序或包含标识列的查询中支持Skip方法, 我有什么理由放弃, 除非性能真的到了非常Critical的时候, 看看下面的分页API, 多么简单:
return q.Skip<Order>((currentPage - 1) * pageSize).Take< Order >(pageSize)
生成的T-SQL语句:
SELECT [t2].[OrderID], [t2].[OrderNumber], [t2].[OrderName], [t2].[DateSubmitted], [t2].[SubmittedBy], ([t2].[LastName] + @p2) + [t2].[FirstName] AS [SubmittedUserName]FROM (SELECT TOP (10) [t0].[OrderID], [t0].[OrderNumber], [t0].[OrderName], [t0].[SubmittedBy], [t0].[DateSubmitted], [t1].[FirstName], [t1].[LastName]FROM [dbo].[Order] AS [t0]INNER JOIN [dbo].[Users] AS [t1] ON [t1].[UserID] = [t0].[SubmittedBy]WHERE ([t0].[NextProcessedBy] = @p0) AND ([t0].[CurrentState] = @p1)) AS [t2]– @p0: Input NVarChar (Size = 3; Prec = 0; Scale = 0) [jlv]– @p1: Input NVarChar (Size = 3; Prec = 0; Scale = 0) [New]– @p2: Input NVarChar (Size = 2; Prec = 0; Scale = 0) [, ]DLINQ生成的SQL语句是利用TOP和嵌套子查询, 这种方法已经被证明是比较高效的做法(相比于临时表的做法), 所以完全有理由可以一试.到这里, List, IQueryable, IQueryable都没有任何问题.
3、需要一个动态排序功能, 这里List的局限性出来了, 传统的做法可能需要用一个dynamic参数来传递需要排序的列然后到SP当中来执行, 但我们已经不打算使用SP了, 也没有动态sql语句, 所有的东西都是强类型的, 然后有LINQ to SQL在运行时来帮我们转换为T-SQL语句。首先List的话, 我们不知道到底哪个字段要排序, 如果使用字符串作为参数的话, 例如放一个string sortBy作为方法的参数, 那么在方法体内就需要做if…else或者switch的判断, 而且还要考虑倒序还是正序的排序要求, 而且你还要hard code,很明显麻烦来了.然而如果使用IQueryable却可以很好的解决所有的这些问题. 但是IQueryable不能跨assembly, 一旦跨了assembly的话, 你无法使用var来引用匿名类里面的property, 绑定到control是没有问题的, 但是客户端的动态查询却成了问题, 因为你根本不知道匿名类是什么. 那么选择IQueryable<T>, 我们选择返回IQueryable<T>给客户端, 分页/排序都没有任何问题.
