ivalueconverter対system.converter対デリゲート

Question

私はConvertingCollectionを実装しています。ConvertingCollectionは、元のアイテム（A）のライブコレクションがあれば、変換されたアイテム（B）のコレクションを提供することを目的としています。コレクションBは、コレクションAで発生した変更を反映します。ターゲットはMVVMでモデルコレクションを使用してViewModelのコレクションとして使用することですが、さまざまな状況で使用できると考えています。

このクラスでは、オブジェクトをタイプAからタイプBに変換する方法を提供する必要があります。進めるにはいくつかの方法がありますが、最適なアプローチを決定するために、 ：

• 私はIValueConverterを尋ねることができました。これはWPF関連のようです。さて、他の場所で使用することはできませんが、混乱するかもしれません。私のクラスは、WPFのコンテキストで最初に使用されることを意図していますが、他の多くのコンテキストにも適用できるほど一般的です。さらに、IValueConverterはオブジェクトからオブジェクトに変換します。これは下流にキャストすることを意味し、ビルド時にはクラッシュしません。

• 私はSystem.Converterを選ぶことができました。これにより、asyncの使用が可能になり、より快適に、私は特定のタイプを求めることができます。私が知る限り、これはWPFに関連したものではありません。

• 最後に、TypeIn => TypeOutを実行する代理人と一緒に行くことができます。インスタンス化され、強く型付けされるクラスはなく、ユーザーはIValueConverter、Converter、またはカスタム関数のいずれかを使用してデリゲートを実装できます。今

、私はすべてがちょうど委譲して処理することができたときにConverterとIValueConverterが存在する理由はわかりません。だから私はそこに何かが足りないと思う。

誰でもお手伝いできますか？ ありがとうございます。 よろしくお願いします。

Answer 1

最善のアプローチを私に従っ：

• は、ユーザーがでIValueConverterまたはConverterを使用するかどうかを決定しましょう両方の可能性を提供するクラスを実装します。
• ラムダ式は、簡単にデリゲートの実装を提供するためにユーザー側で使用されるため、範囲外です。これは、ConvertingCollectionがデリゲートをパラメータとして期待していることを意味します。これはConverterです。それはいてもよく、ConvertingCollectionの使用方法の唯一のコンテキストで任意の場所にしていないだけで適用できる変換を提供するために、ユーザーを強制的に
  • ：ので、最後に、暗黙の型変換を使用するためのアイデアが保持されていない
  • 時々
  • 暗黙の変換が適用される場合には、問題は、ラムダ式は、より複雑なConvertingCollectionの実装（暗黙的な変換は、2種類のAとBの間に存在するかどうかをチェック）を行う
  • で使用することが容易であり、私はこれにはあまりにも怠惰です。それは最初の理由かもしれませんが、他の2つはまだ有効です。 :)

私はこれが役立ちます。

Answer 2

ぼんやりとした詳細はわかりませんが、implicitの演算子も使用できます。この要約それぞれのタイプに変換し、それが絶対的に些細な実際のインスタンスの変換を書いてます両方：

A myA = new A(); 
//implicit conversion happens here 
B myB = myA; 

class A 
{ 
    public static implicit operator A(B b) 
    { 
     //TODO - Convert b to a new A 
     return new A(); 
    } 
} 

class B 
{ 
    public static implicit operator B(A a) 
    { 
     //TODO - Convert a to a new B 
     return new B(); 
    } 
}