2

私は linq ステートメントを単純に書き出すことに気づきましたが、他の人が冗長な方法と定義している可能性があります。

簡単な例:

return _entries
    .Where(x => x.Context.Equals(context))
    .Where(x => x.Type == typeof (T))
    .Select(x=>x.Value)
    .Cast<T>()
    .Single();

次のように簡略化できます。

return _entries
    .Where(x => x.Context.Equals(context) && x.Type == typeof (T))
    .Select(x=>(T)x.Value)
    .Single();

[質問] 長い目で見た場合、どちらのコーディング方法が優れていますか? つまり、長い (そして単純な) linq チェーンか、より複雑なセレクターを備えた短い linq チェーンか?

これらの Linq ステートメントがコンパイラによって最適化されると仮定するのは正しいですか?

4

4 に答える 4

9

長期的に見て、どちらがより良いコーディング プラクティスですか?

私は短くてシンプルな方が好きです。それはより読みやすいです。LINQ の要点は、ビジネス ドメインのロジックのようにコードを読みやすくすることです。

これらの Linq ステートメントがコンパイラによって最適化されると仮定するのは正しいですか?

いいえ; 最適化は、コンパイラではなくランタイムによって行われます。記述したパターンに従うLINQ-to-objectsの「Where」句と「Select」句は、実行時に単一の「where-select」オブジェクトに最適化され、作成される反復子が多すぎないようにします。(Jon Skeet が発見したように、実際にはパフォーマンスが低下する状況が時々発生する可能性があります。ほとんどすべての「最適化」と同様に、100% 成功するわけではありません。残念ながら、現時点では、Jon の記事を見つけることができません。 )

于 2013-03-01T17:50:49.067 に答える
5

いいえ、これらのLINQステートメントがコンパイラによって最適化されていると想定するのは正しくありません。より冗長な構文はより多くのEnumeratorオブジェクトを生成するため、2つは同等ではありません。パフォーマンスの観点からは、構文が短いほど（わずかに）優れています。

ただし、読みやすさとコーディングの観点から2つの構文のどちらかを選択する場合は、最初の構文を使用します。これは、より適切に実行される手順を示しているためです。パフォーマンスのボトルネックがあることを証明できる場合を除いて、私は常にパフォーマンスよりも読みやすさを好みます。

ただし、便利なOfType<T>()LINQ演算子があります。あなたの最初の例は、書き直されました：

return _entries
    .Where(x => x.Context.Equals(context))
    .OfType<T>()
    .Select(x => (T)x.Value)
    .Single();
于 2013-03-01T17:04:00.760 に答える
1

コードの意図を宣言的に表現する方法を提供してくれるので、Linq 式が大好きです。どのように達成するかではなく、何を達成したいかを重視します。そのため、コードの読みやすさを重視してください。

ただし、一部の for/foreach ブロックを Linq 演算子に置き換えると、コードの実現が煩雑になる場合もあります。したがって、共同プログラマーにロジックを口頭で説明するように、式を詳細に記述することをお勧めします。たとえば、以下の式は、次のように記述できます。 T"に等しい。As<T>()必要に応じて、値を T 型にキャストするなどのカスタム拡張メソッドを記述します。

return _entries
    .Where(x => x.Context.Equals(context) && x.Type == typeof (T))
    .Single (x=> x.Value)
    .As<T>();
于 2013-03-02T07:13:13.850 に答える