在视图模型中具有WPF细节的优缺点

Question

我无法决定如何考虑这段代码：

public SolidColorBrush Brush
{
    get { return IsValid ? _validItemBrush : _invalidItemBrush; }
}

它是我当前项目中视图模型的一部分，您可以想象，Brush将绑定到UI中的某些文本元素，以指示（in-）其他数据片段的有效性，在另一个相当简单明了的对话框中。

这段代码的支持者说，既然我们正在使用WPF，我们也可以在视图模型中允许一些简单的WPF特定结构。

反对者说这违反了 Disparation of Concerns ，因为它明确规定了应该仅由观点来处理的风格。

请分享您的论点，如果您对上述代码不满意，请分享您对其他解决方案的看法。 （我对你使用DataTemplate s）所说的内容特别感兴趣。

是否有可能被认为是最佳实践的解决方案？

Answer 1

就个人而言，我会在XAML中定义两个画笔，并使用基于IsValid属性的控件来使用它们切换画笔（在xaml中）。这可以通过DataTriggers甚至单个IValueConverter轻松完成 - 转换器可以使用2个画笔和布尔值，并且可以非常轻松地在它们之间进行交换。

这使业务逻辑呈现中性 - “刷子”非常特定于特定的表示形式，以及纯粹的View选择。将其硬编码到ViewModel中违反了单一责任原则，并且不是关注点的清晰分离。

我非常希望将其保留在View中，并根据ViewModel特定的IsValid（绑定）属性进行切换。

Answer 2

虽然在某些情况下我可能会在视图模型中使用WPF结构，但这不是其中之一。原因如下：

• 改变起来比较困难。如果将画笔定义为资源并在样式中使用它们，则更改应用程序的颜色方案只需加载不同的资源字典即可。如果您在视图模型中对颜色值进行硬编码，那么如果最终用户需要不同的颜色，则需要更改许多不同的内容。

• 测试起来比较困难。如果你想编写一个单元测试来检查属性是否正在返回正确的画笔，你必须在单元测试中创建一个画笔并比较两者的值，因为它是一个引用类型。

  < / LI>

• 在许多情况下，甚至大多数情况下，它都不会使代码更简单或更容易维护。你很可能已经在使用一种风格（假设你熟悉风格），因为它们使WPF中的所有内容变得更容易。将IsValid绑定到画笔颜色只需在样式中添加DataTrigger即可。维护此代码的任何人都希望找到它。

我肯定会在视图模型中使用WPF构造 - 例如，很久以前，如果视图模型公开了Visibility类型的属性，很久以前就不知道是否存在问题。请注意，上述问题均不适用于该情况。

Answer 3

在像你这样纯粹美学的情况下，我使用触发器或视觉状态管理器来改变颜色。

有时我会在我的ViewModel中使用颜色，但前提是它的部分软件规格（例如，显示患者二氧化碳的图表颜色取决于本地化）。在这种情况下，我使用Color struct bound属性，允许View将Color用于SolidColorBrush，GradientStop或其他任何想要的东西。我最初使用#AARRGGBB格式的字符串来完全删除WPF依赖，但我的经验丰富的同事并不喜欢这样。