LINQを使用してオブジェクトリスト内のメンバ変数の値をマスクする方法はありますか？

Question

グリッドに表示しているテーブルがあります。同じ列の別の値がある条件を満たす場合、特定の列の値をマスクするように求められています。

例を見てみましょう：それには「特別な」

var filteredList = from container in myContainerList 
        let vol = container.Name.ToUpper().Contains("SPECIAL") ? 
                 -1 : container.Volume 
        select new Container() 
        { 
         Name = Name, 
         Volume = vol 
        }; 

これに成功したマスク名前を持つ容器の容積：

public class Container 
{ 
    public string Name { get; set; } 
    public int Volume { get; set; } 
} 

IQueryable<Container> myContainerList; 
// Imagine some code to populate the object 

現在、私はそうのようなボリュームフィールドをマスキングしていますしかし、これは私にとっては非効率的です。

これについては、より良い方法がありますか？

Answer 1

私はコンテナクラスに別のプロパティを追加したい：

public string MaskedVol 
{ 
    get 
    { 
    return (Name.IndexOf("SPECIAL", StringComparison.OrdinalIgnoreCase) != -1) ? "--" : Volume.ToString(); 
    } 
} 

Answer 2

私はショーンに同意読み取り専用プロパティを追加することは、おそらく最良の選択肢であること。あなたがContainerクラスを変更したくない場合は、あなたのLINQクエリは少し簡略化することができるより：

var filteredList = myContainerList.Select(c => new Container { 
    Name = c.Name, 
    Volume = c.Name.ToUpper().Contains("SPECIAL") ? -1 : c.Volume 
}); 

Answer 3

をなぜこれがあなたに非効率的なように見えるのでしょうか？
各項目について、ちょうど1回のチェックが行われるため、プロセスのスピードアップの仕方がわかりません。

ToUpperで新しい文字列を作成し、Containsを呼び出す代わりに、IndexOfを使用すると、少し速く、リソースを消費することができます。

次にComponentのマスクVolumeの義務であるかどうかを決定します。
は、それは、クエリ内の混乱を取り除くためにそれに特別なプロパティを宣言している場合：マスキングについて知るための責任ではないContainerさんなら

public class Container 
{ 
    public string Name { get; set; } 
    public int Volume { get; set; } 

    public int MaskedVolume { 
     get { 
      return (Name.IndexOf ("SPECIAL", StringComparison.OrdinalIgnoreCase) >= 0) 
       ? Volume 
       : -1; 
     } 
    } 
} 

、私はラムダがletより良いフィット感であることをElianに同意します：私に警告何

var filteredList = list.Select (c => 
    new Container { 
     Name = c.Name, 
     Volume = (c.Name.IndexOf ("SPECIAL", StringComparison.OrdinalIgnoreCase) >= 0) 
        ? c.Volume 
        : -1 
    }); 

は、しかし、あなただけのリストビューに表示しComponentの別のインスタンスを作成するという事実です。これは本当ですか？ Componentがビジネスロジックの一部であり、確かにビジネスロジックの観点から、新しいリストビューが作成されるたびに新しいComponentが作成されないようです。

この場合、ソリューションを再検討する必要があります。 Componentがアプリケーションでどのように使用されているかについて、詳細を教えてください。