ivalueconverter vs system.converter vs delegate

Question

>我正在实现一个转换集合，它旨在提供转换项目(B)的集合，给定原始项目的实时集合(A)。集合 B 将反映集合 A 中发生的任何更改。目标是在 MVVM 中将其用作给定模型集合的 ViewModels 集合，但我相信它可以在许多不同的上下文中使用。

此类要求用户提供一种将对象从类型 A 转换为类型 B 的方法。我可以找到几种方法进行，但我对它们的差异了解不足，无法决定什么是最佳方法：

• 我可以要求一个IValueConverter，这似乎与WPF有关。现在，没有什么可以阻止在其他地方使用它，但它可能会令人困惑。尽管我的类最初打算在 WPF 上下文中使用，但它足够通用，可以应用于许多其他上下文。此外，IValueConverter从一个对象转换到另一个对象，这意味着在下游转换，并且在构建时不会崩溃。

• 我可以选择System.Converter.这允许使用async，更令人愉快的是，我可以要求特定的类型。另外，据我所知，这在人们的脑海中与WPF无关。

• 最后，我可以和一个代表一起做TypeIn => TypeOut。没有要实例化的类，强类型，用户可以使用 IValueConverter、Converter 或自定义函数中的任何一个来实现委托。

现在，我不知道为什么当一切都可以用代表来处理时，Converter和IValueConverter存在。所以我想我在那里错过了一些东西。

任何人都可以帮忙吗？ 提前感谢， 此致敬意

Answer 1

我不知道所有的细节，但你也可以使用隐式运算符。 这两者都将转换抽象为各自的类型，并且使编写实际的实例转换变得绝对微不足道：

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

Answer 2

根据我的最佳方法：

• 让用户通过实现提供这两种可能性的类来决定是使用IValueConverter还是Converter。
• lambda 超出了范围，因为 lambda 表达式是在用户端用来轻松提供委托实现的表达式。这意味着ConvertingCollection期望委托作为参数，这就是Converter已经存在的内容。
• 最后，没有保留使用隐式转换的想法，因为：
  • 它迫使用户提供可以在任何地方应用的转换，而不仅仅是在使用ConvertingCollection的唯一上下文中，这有时可能会出现问题
  • 如果应用隐式转换，则很容易在 lambda 表达式中使用它
  • 它使ConvertingCollection的实现更加复杂(检查 2 种类型 A 和 B 之间是否存在隐式转换)，我懒得这样做。好吧，这可能是第一个原因，但其他两个仍然有效。:)

我希望这有所帮助。