Question

我正在实施一个ConvertingCollection，它旨在提供一系列转换项目（B），给出原始项目的实时集合（A）。集合B将反映集合A中发生的任何变化。目标是在MVVM中将其用作给定模型集合的ViewModel集合，但我相信它可以在许多不同的上下文中使用。

这个类要求用户提供一种方法，将对象从类型A转换为类型B.我可以找到几种方法继续，但我不太了解它们的差异，以决定什么是最好的方法：

我可以要求IValueConverter，这似乎与WPF有关。现在，没有什么可以阻止在其他地方使用它，但它可能会令人困惑。虽然我的类首先打算在WPF上下文中使用，但它足够通用，可以应用于许多其他上下文。另外，IValueConverter从对象转换为对象，这意味着向下游进行转换，并且在构建时不会崩溃。
我可以选择System.Converter。这允许async的使用，更令人愉快，我可以要求特定的类型。另外，据我所知，这与人们的想法不是WPF相关的。
最后，我可以和代表一起去做TypeIn =＆gt; TypeOut。没有类可以实例化，强类型化，用户可以使用任何IValueConverter，Converter或自定义函数来实现委托。

现在，我不知道为什么Converter和IValueConverter存在，只需代表处理一切。所以我想我错过了一些东西。

有人可以帮忙吗？提前致谢，最好的问候

Answer 1

我不知道所有细节，但您也可以使用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();
    }
}

Answer 2

根据我的最佳方法：

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

我希望这会有所帮助。

ivalueconverter vs system.converter vs delegate

2 个答案: