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から派生します。ICollectionIEnumerable

別のクラスには、次のようなコードがあります。

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

そのような場合、なぜ遅延実行を使用するのですか? 最初にAsQueryable<IconSize>()コレクションに使用し、次にLINQと遅延実行を使用するのはなぜですか?

単純なリストを使用する場合と比較して利点はありますか?

4

3 に答える 3

1

これらの場合、実質的な利点はありません。を使用するIQueryableと、クエリの書き換え/変換によってパフォーマンスが最適化される場合に役立ちます。提供された例では、実際にパフォーマンスが低下します。

有用な方法で使用IQueryableする 1 つの例は、データベースまたは Web サービスに対してクエリを遅延変換および評価するときに得られる大幅なパフォーマンスの向上です。これは、大量の結果セットを取得し、「単純なリスト」を使用してアクティブ メモリにクエリ ロジックを適用するという代替手段よりもはるかに優れたパフォーマンスを発揮します。

あなたのケースで を使用すると有害であることがわかる方法はIQueryable、クエリを開始したときに、コレクションが既にメモリにロードされていることです。

于 2013-05-02T13:18:32.623 に答える
0

ユーザーが結果セットを使用しない可能性があり、データ ソースを照会する意味がないため、遅延実行は適切です。

結果を IQueryable にキャストしない限り、ユーザーが使用できない LINQ メソッドがいくつかある場合があります。これは、ユーザーができることを制限したり、リストをより便利なものにキャスト/コピーするように強制したりする可能性があることを意味します。

リストを使用する場合、ソリューションをリストにハードコーディングしています。コレクションの実装が何であるかを気にしますか?ユーザーは...おそらく、必要なインターフェイスをサポートしている限りではありません。

于 2013-05-02T13:21:42.487 に答える