做或不​​做。 MVVM中的价值转换器

Question

我正在寻找确认/验证我所做的事情是否遵循该模式，并且是最佳实践，或者是有人以口头形式滥用我提交的内容！

如果我在[insert control here]上执行Visibility绑定，我将它绑定到System.Windows.Visibility类型的属性。然后根据业务逻辑将此值设置为可见/折叠。其中一个潜在的缺陷是，我的虚拟机属性现在直接绑定到我可以看到被抽象为值转换器的类型。据说，我经常在MVVM的讨论中读到ValueConverters不应该被使用。

我可以得到一些反馈吗？

谢谢！

SS

Answer 1

我是转换器的粉丝，但专门用于重复使用。在ViewModel中做这些转换可能很容易，但是如果你想在许多ViewModel甚至15个不同的应用程序中进行相同的转换呢？如果你仅限于ViewModel方法，那么你会违反DRY。这就是说，我不能同意更多转换器不应该包含业务逻辑，不应该用于“一次性”解决方案。

在上面提到的情况下，它需要在您的ViewModel中具有Visibility类型的属性，这对我来说是一种代码味道。恕我直言，ViewModels不应该反映视觉状态，而是视图的视觉状态应该对ViewModel的数据状态作出反应。

Answer 2

这是一个有争议的话题，但我坐在军营，在那里，我认为你不应该使用转换器。 ViewModel被认为是“类固醇转换器”，所以你不需要任何转换器。 （http://groups.google.com/group/wpf-disciples/browse_thread/thread/3fe270cd107f184f?pli=1）

如果使用转换器，你会发现，他们在你的项目中无处不在结束了最平凡的事情。例如：想要显示“3位顾客”，但如果是“1位顾客”，则没有复数。在一个视图模型中很容易做到，但在转换器中非常繁琐。

Answer 3

我认为在常见的UI场景中使用值转换器是完全可以的（例如将可见性绑定到布尔属性）。但是，仅将它们用于纯粹与UI相关的任务：不要在转换器中放置任何业务逻辑，它不属于此类。

Answer 4

视图（XAML/WPF）和ViewModel负责不同的事情。因此，如果您操作ViewModel提供的数据，最好在ViewModel中进行转换。但是，如果您需要纯粹的UI元素转换，那么视图是最适合它的地方。

E.G.我认为可见性是ViewModel的责任，因为可能存在一些关于正在显示的业务规则。然而，如果您要更改标签，复杂性可能应该是UI的责任。除此之外，你可能会决定使用触发器而不是转换器。这不应该是ViewModel的问题。

我不相信你不应该使用某些东西，因为正在使用某种模式。这是一个关于何时应用它的判断，以及它是否使得代码可测试，可维护且易于理解，同时提供高质量的应用程序。