ivalueconverter vs system.converter vs Delegat

Question

Ich implementiere eine ConvertingCollection, die eine Sammlung von konvertierten Elementen (B) bietet, mit einer Live-Sammlung von Originalartikeln (A). Die Sammlung B würde alle Änderungen widerspiegeln, die in Sammlung A auftreten. Das Ziel besteht darin, sie in MVVM als eine Sammlung von ViewModels mit einer Sammlung von Modellen zu verwenden, aber ich glaube, dass sie in vielen verschiedenen Kontexten verwendet werden könnte.

Diese Klasse erfordert vom Benutzer eine Möglichkeit, Objekte von einem Typ A in einen Typ B zu konvertieren. Ich kann verschiedene Wege finden, um fortzufahren, aber ich weiß nicht genug über ihre Unterschiede, um zu entscheiden, was der beste Ansatz ist :

• ich für ein IValueConverter fragen konnte, die WPF-verwandt zu sein scheint. Jetzt hindert nichts daran, es woanders zu verwenden, aber es könnte verwirrend sein. Obwohl meine Klasse zuerst in einem WPF-Kontext verwendet werden soll, ist sie generisch genug, um sie auf viele andere Kontexte anzuwenden. Darüber hinaus wird IValueConverter von Objekt zu Objekt konvertiert, was bedeutet, dass das Streaming nach dem Downstream erfolgt und kein Crash während der Erstellung stattfindet.

• Ich könnte für eine System.Converter entscheiden. Dies ermöglicht die Verwendung von async und, noch angenehmer, kann ich nach bestimmten Typen fragen. Außerdem ist dies, soweit ich weiß, nicht im Zusammenhang mit WPF.

• Schließlich könnte ich einfach mit einem Delegaten TypIn => TypeOut tun gehen. Keine einzugebende Klasse, stark typisiert, und der Benutzer könnte einen beliebigen IValueConverter, Converter oder eine benutzerdefinierte Funktion verwenden, um den Delegaten zu implementieren.

Nun, ich habe keine Ahnung, warum die Converter und IValueConverter existieren, wenn alles mit nur Delegierten behandelt werden könnten. Also ich denke ich vermisse dort etwas.

Kann mir bitte jemand helfen? Vielen Dank im Voraus, Mit freundlichen Grüßen

Answer 1

Der beste Ansatz nach mir:

• der Benutzer entscheiden lassen, ob IValueConverter oder Converter verwenden, indem eine Klasse implementieren, die beide Möglichkeiten bietet.
• Das Lambda liegt außerhalb des Gültigkeitsbereichs, da auf der Benutzerseite ein Lambda-Ausdruck verwendet wird, um eine Delegate-Implementierung einfach bereitzustellen. Dies bedeutet, dass ein ConvertingCollection einen Delegaten als Parameter erwarten würde, was ein Converter bereits ist.
• schließlich auf der Idee, eine implizite Konvertierung zu verwenden ist nicht gehalten, weil:
  • es den Benutzer zwingt, eine Umwandlung zu schaffen, die überall und nicht nur in dem einzigen Zusammenhang mit der Nutzung von ConvertingCollection gelten könnten, was sein kann, manchmal problematisch
  • falls eine implizite Konvertierung gilt, ist einfach ist es, in einem Lambda-Ausdruck zu verwenden
  • es, die Umsetzung der ConvertingCollection komplexen macht (überprüfen, ob eine implizite Konvertierung zwischen dem 2 Typ A und B vorhanden ist), und ich bin zu faul dafür. Ok, das mag der erste Grund sein, aber die anderen beiden sind immer noch gültig. :)

Ich hoffe, das hilft.

Answer 2

Ich weiß nicht alle dreckigen Details, aber Sie könnten auch den implicit Operator auch verwenden. Diese beiden Abstracts Umwandlung in ihre jeweiligen Typen und es macht das Schreiben der aktuellen Instanz Conversions absolut trivial:

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(); 
    } 
}