原文摘自：http://tech.it168.com/d/2008-01-16/200801161604779.shtml
这是我决定将LINQ to SQL集成到应用程序中一开始就一直在考虑的一个问题, 到底应该返回IQueryable<T>还是IQueryable? 或许这个列表还应该继续扩展为T,List<T>, object[], 对于Business Layer来说, 到底应该选择哪一种?
我最后的选择是T和IQueryable<T>, T很明显是针对于单个实体对象, 我认为针对只返回一个确定对象的情况下, 客户端很少需要再次利用IQueryable的能力进行二次筛选和操作, 而且方法体可以明确表明就是这返回一个对象或者null, 这一点我想应该没有太多异议.
对于集合列表, 的确是一个很难得选择, 我一次试图直接返回List, 这是很直观的, 因为2.0的时候我一直就是这么干的, 所以很自然我认为LINQ to SQL不应该有什么问题会阻止我这么做? 实际上, 这也的确没有什么太多的问题, 例如:
var q = from c in dataContext.ClaimRequests where c.NextProcessedBy == userID && c.CurrentState == state select c; return q.ToList < ClaimRequest > ();
ok, 进一步的需求来了, 首先我需要一个分页功能; 到这一步的时候我又有几个选择, 利用LINQ to SQL可以执行自定义存储过程的功能, 完全自己写, 这个可以工作很好, 问题是我很懒, 更重要的时候LINQ to SQL本身已经有API提供了分页功能了, 我有什么理由放弃, 除非性能真的到了非常Critical的时候, 看看下面的分页API, 多么简单:
return q.Skip < ClaimRequest > ((currentPage - 1 ) * pageSize).Take < ClaimRequest > (pageSize)
生成的T-SQL语句:
SELECT [ t2 ] . [ ClaimRequestID ] , [ t2 ] . [ ClaimNumber ] , [ t2 ] . [ ClaimName ] , [ t2 ] . [ DateSubmitted ] , [ t2 ] . [ SubmittedBy ] , ( [ t2 ] . [ LastName ] + @p2 ) + [ t2 ] . [ FirstName ] AS [ SubmittedUserName ] FROM ( SELECT TOP ( 10 ) [ t0 ] . [ ClaimRequestID ] , [ t0 ] . [ ClaimNumber ] , [ t0 ] . [ ClaimName ] , [ t0 ] . [ SubmittedBy ] , [ t0 ] . [ DateSubmitted ] , [ t1 ] . [ FirstName ] , [ t1 ] . [ LastName ] FROM [ dbo ] . [ ClaimRequest ] 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都没有任何问题.
接下来我还需要一个动态排序功能, 这里List的局限性出来了, 传统的做法可能需要用一个dynamic参数来传递需要排序的列然后到SP当中来执行, 但这里我们已经不打算使用SP了, 也没有动态sql语句, 所有的东西都是强类型的, 然后有LINQ to SQL在运行时来帮我们转换为T-SQL语句。首先List的话, 我们不知道到底哪个字段要排序, 如果使用字符串作为参数的话, 例如放一个string sortBy作为方法的参数, 那么在方法体内就需要做if…else或者switch的判断, 而且还要考虑倒序还是正序的排序要求, 而且你还要hard code,很明显麻烦来了.
然而如果使用IQueryable却可以很好的解决所有的这些问题. 这里需要说明一下IQueryable<T>和IQueryable, 在没有涉及排序之前, 我想当然的选择了IQueryable, 原因是我不想返回实体类的所有字段以及它的Association类的所有字段,因为这样可以提供更好的性能, 所以自然而然的我选择了返回匿名类, 类似这样:
var q = from c in dataContext.ClaimRequests where c.NextProcessedBy == userID && c.CurrentState == “New” select new {ClaimRequestID = c.ClaimRequestID, ClaimNumber = c.ClaimNumber, ClaimName = c.ClaimName, DateSubmitted = c.DateSubmitted, SubmittedBy = c.SubmittedBy, SubmittedUserName = c. User .LastName + “, “ + c. User .FirstName};
但是我没有考虑到IQueryable不能跨assembly, 一旦跨了assembly的话, 你无法使用var来引用这个匿名类里面的property, 绑定到control是没有问题的, 但是客户端的动态查询却成了问题, 因为你根本不知道匿名类是什么.
最后让我们来看最后的选择IQueryable<T>, 我们选择返回IQueryable<T>给客户端, 分页 / 排序都没有任何问题, 且默认情况下我们返回了实体类的所有字段, 至于是否返回了Association类的信息则取决于绑定情况, 而且这里要非常注意, 如果你不小心在前端绑定代码中使用Association类的字段, 例如ClaimRequest.User.LastName这类的信息很有可能会执行n条的SQL语句, 这个要非常注意, 时刻注意生成的SQL语句的情况是个好的习惯. 为了取得更好的性能, 我还是希望能够使用匿名类来过滤我不需要的字段, IQueryable<T>做到这个完全没有问题, 类似这样:
var q = ClaimRequestManager.GetPagedClaimRequests(((MasterPage)this.Master).GetUserID(), STATE_NAME, myPager.PageSize, myPager.PageIndex + 1 , out totalRecords); // fields what we need var filter = q. Select (c => new { ClaimRequestID = c.ClaimRequestID, ClaimNumber = c.ClaimNumber, ClaimName = c.ClaimName, DateSubmitted = c.DateSubmitted, SubmittedBy = c.SubmittedBy, SubmittedUserName = c. User .LastName + “, “ + c. User .FirstName } ); rptValidatingReqList.DataSource = filter; rptValidatingReqList.DataBind();
GetPagedClaimRequests实际上包含了ClaimRequest所有字段的信息, 当然并没有实际执行, 除非你绑定到控件上. 然后客户端可以自己选择到底要使用哪些字段, 尤其IQueryable<T>包含了T所关联的所有信息, 我们可以选择关系类的其他字段进行操作, 过滤后最终进行绑定, 最终我们选择了IQueryable<T>, 强类型 + 灵活的动态查询一样也不差. 有了IQueryable<T>, 某些情况下我们可能就要和匿名类打交道了.
扫一扫
6398
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
