问题描述
|
我正在寻找确认/确认我正在做的事情符合该模式并且是最佳实践，或者正在寻找有人口头虐待我以使其屈服！
如果在[此处插入控件]上进行可见性绑定，则将其绑定到类型为System.Windows.Visibility的属性。然后，根据业务逻辑将此值设置为“可见/崩溃”。一个潜在的缺陷是我的VM属性现在直接绑定到我可以看到抽象为valueconverter的类型。话虽如此，我经常在MVVM讨论中读到不应该使用ValueConverters。
请问我能得到一些反馈吗？
谢谢！
SS
解决方法
我是Converters的粉丝，但专门用于重用。在ViewModel中进行这些转换可能很容易，但是如果您希望在许多ViewModel甚至15个不同的应用程序中进行相同的转换怎么办？如果将自己限制为仅使用ViewModel方法，则将违反DRY。话虽如此，我完全同意转换器不应包含业务逻辑，也不应该用于“一次性”解决方案。
在上面提到的情况下，它在ViewModel中需要一个Visibility类型的属性，这对我来说是代码的味道。恕我直言，ViewModels不应反映视觉状态，而是View的Visual状态应对ViewModel的数据状态做出反应。
, 我认为在常见的UI场景中使用值转换器是完全可以的（例如将可见性绑定到布尔属性）。但是，仅将它们用于纯粹与UI相关的任务：不要在转换器中放置任何业务逻辑，它不属于转换器。
, 这是一个有争议的话题，但是我坐在营地中，我认为您不应该使用转换器。 ViewModel被认为是“类固醇转换器”，因此您不需要任何转换器。
（http://groups.google.com/group/wpf-disciples/browse_thread/thread/3fe270cd107f184f?pli=1）
如果您使用转换器，您会发现它们最终会出现在项目中的任何地方，都是最平凡的事情。例如：要显示“ 3位客户”，但如果是“ 1位客户”，则不能显示复数。在viewModel中很容易做到，但在转换器中却很快就能得到乏味的真实结果。
, 视图（XAML / WPF）和ViewModel负责不同的事情。因此，如果要处理ViewModel提供的数据，则最好在ViewModel中进行转换。但是，如果仅需要UI元素的转换，则视图是最佳选择。
例如。我想说，可见性是ViewModel的责任，因为围绕显示的内容可能存在一些业务规则。但是，在更改标签的地方，复数可能应该是UI的责任。此外，您可能决定使用触发器而不是转换器。这对于ViewModel来说应该不是问题。
我不认为您不应该使用某些东西，因为正在使用某种模式。在提供高质量的应用程序时，要对是否应用它以及是否使代码可测试，可维护并且易于理解进行判断。