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>给客户端, 分页/排序都没有任何问题.
本文转自 张善友 51CTO博客，原文链接：http://blog.51cto.com/shanyou/73895，如需转载请自行联系原作者
