2

我有一个项目实现了自己的配置类：

IconSizesConfigSection: ConfigurationSection
IconSizesCollection: ConfigurationElementCollection
IconSize: ConfigurationElement

在Config类中存在这个属性：

public IQueryable<IconSize> IconSizes
    {
        get 
        {
            IconSizesConfigSection configInfo = (IconSizesConfigSection)ConfigurationManager.GetSection("iconConfig");
            return configInfo.IconSizes.OfType<IconSize>().AsQueryable<IconSize>(); 

        }
    }

IconSizesIconSizesCollection派生自 的属性返回ConfigurationElementCollection。反过来ConfigurationElementCollection衍生自ICollection, IEnumerable。

在另一个类中，我有这样的代码：

var previewIconSize = Config.IconSizes.FirstOrDefault(c => c.Name == "AvatarSize");

为什么在这种情况下使用延迟执行？为什么最初它AsQueryable<IconSize>()用于收集，然后使用 LINQ 和延迟执行？

与使用简单列表相比有什么好处吗？

4

3 回答 3

1

在这些情况下，没有实际的好处。使用IQueryable对于查询重写/翻译将优化性能的情况很有帮助。在提供的示例中，您实际上会降低性能。

以一种有用的方式使用的一个示例是，IQueryable在针对数据库或 Web 服务进行延迟转换和评估查询时获得显着的性能提升。这将比使用“简单列表”提取大量结果集并在活动内存中应用查询逻辑的替代方案执行得更好。

您可以判断IQueryable在您的情况下使用的方式是有害的，当您开始查询时，集合已经加载到内存中。

于 2013-05-02T13:18:32.623 回答
1

IEnumerable 和 IQueryable 都使用延迟执行。不同之处在于 IQueryable 用于跨越数据库查询、实体框架查询或 OData 查询等边界。

当一个 IQueryable 被迭代时，查询被翻译成远程提供者的习惯用法并在那里执行。当从远程提供者接收到响应时，它被转换为本地对象表示。

于 2013-05-02T21:53:49.853 回答
0

延迟执行很好，因为您的用户可能永远不会使用结果集，因此查询数据源没有意义。

您的用户可能无法使用某些 LINQ 方法，除非他们将结果转换为 IQueryable，这意味着您可能会限制他们可以执行的操作，或者强制他们将列表转换/复制为更有用的内容。

如果您使用列表，那么您正在将您的解决方案硬编码为列表，您是否关心集合的实现是什么，您的用户是否......只要它支持必要的接口就可能不关心。

于 2013-05-02T13:21:42.487 回答