LINQ与基于传统集合的方法之间的优缺点
我想知道,对于.net游戏而言,它相对较新,是否有人在使用LINQ与使用列表/集合进行比较传统的方法之间有什么利弊经验?
对于我正在处理的项目的特定示例:正在从远程Web服务检索唯一ID /名称对的列表。
- 该列表很少更改(每天一次),
- 从使用它的应用程序的角度来看,它将是只读的
- 将存储在应用程序级别以供所有访问请求
考虑到这些要点,我计划将返回的值存储在应用程序级别的单例类中。
我最初的方法是遍历从远程服务返回的列表,并将其存储在singleton类的NameValueCollection中,并使用基于id从集合中检索的方法:
sugarsoap soapService = new sugarsoap(); branch_summary[] branchList = soapService.getBranches(); foreach (branch_summary aBranch in branchList) { branchNameList.Add(aBranch.id, aBranch.name); }
使用LINQ的替代方法是简单地添加一个一旦检索到就可以直接在列表上使用的方法:
public string branchName (string branchId) { //branchList populated in the constructor branch_summary bs = from b in branchList where b.id == branchId select b; return branch_summary.name; }
是不是比另一个更好?无论是方法还是解决方案,无论是提供优雅的解决方案还是有益于性能的解决方案,我都乐于接受所有答案。
解决方案
回答
我不确定单例类是否绝对必要,我们是否始终需要全局访问权限?名单很大吗?
我假设我们将在单例类上有一个刷新方法,用于确定何时需要更改属性,并且我们还可以通过某种方式通知单例在列表更改时进行更新。
两种解决方案都是可行的。我认为LINQ将在构造函数中更快地填充集合(但不会明显更快)。传统的基于集合的方法很好。就个人而言,我会选择LINQ版本,只是因为它是一项新技术并且我喜欢使用它。假设部署环境具有.NET 3.5 ...
Web服务上是否有一种通过ID获取分支的方法?如果不经常需要分支信息,那将是第三个选择。
回答
我不认为我们编写的linq可以编译,
public string branchName (string branchId) { //branchList populated in the constructor branch_summary bs = (from b in branchList where b.id == branchId select b).FirstOrDefault(); return branch_summary == null ? null : branch_summary.name; }
注意.FirstsOrDefault()
我宁愿使用LINQ,因为它可以在其他地方使用,以便在数据上编写更复杂的过滤器。我还认为,比NameValueCollection替代方法更容易阅读。
那是我的0.02美元
回答
通常,简单的单行for / foreach循环将比使用Linq更快。同样,在这种情况下,Linq不会(始终)提供明显的可读性改进。这是我通过以下代码编写的一般规则:
如果该算法足够简单,无需Linq即可编写和维护,并且我们不需要延迟评估,并且Linq没有提供足够的可维护性改进,则不要使用它。但是,有时候Linq极大地提高了代码的可读性和正确性,如我在此处和此处发布的两个示例所示。