LINQ to SQL集成到应用程序中需考虑的一些问题

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语句:
LINQ to SQL集成到应用程序中需考虑的一些问题SELECT [t2].[OrderID][t2].[OrderNumber][t2].[OrderName][t2].[DateSubmitted][t2].[SubmittedBy], ([t2].[LastName] + @p2+ [t2].[FirstName] AS [SubmittedUserName]
LINQ to SQL集成到应用程序中需考虑的一些问题
FROM (
LINQ to SQL集成到应用程序中需考虑的一些问题
SELECT TOP (10[t0].[OrderID][t0].[OrderNumber][t0].[OrderName][t0].[SubmittedBy][t0].[DateSubmitted][t1].[FirstName][t1].[LastName]
LINQ to SQL集成到应用程序中需考虑的一些问题
FROM [dbo].[Order] AS [t0]
LINQ to SQL集成到应用程序中需考虑的一些问题
INNER JOIN [dbo].[Users] AS [t1] ON [t1].[UserID] = [t0].[SubmittedBy]
LINQ to SQL集成到应用程序中需考虑的一些问题
WHERE ([t0].[NextProcessedBy] = @p0AND ([t0].[CurrentState] = @p1)
LINQ to SQL集成到应用程序中需考虑的一些问题
AS [t2]
LINQ to SQL集成到应用程序中需考虑的一些问题– 
@p0: Input NVarChar (Size = 3; Prec = 0; Scale = 0[jlv]
LINQ to SQL集成到应用程序中需考虑的一些问题– 
@p1: Input NVarChar (Size = 3; Prec = 0; Scale = 0[New]
LINQ to SQL集成到应用程序中需考虑的一些问题– 
@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>给客户端, 分页/排序都没有任何问题. 



本文来自云栖社区合作伙伴“doNET跨平台”,了解相关信息可以关注“opendotnet”微信公众号

上一篇:Rails框架流行在他的设计理念


下一篇:从零配置Vue开发webpack环境踩到的坑