在视图模型中包含 WPF 细节的优缺点答案

【问题标题】：Pros and cons of having a WPF specifics in the view model在视图模型中包含 WPF 细节的优缺点
【发布时间】：2011-02-02 00:20:50
【问题描述】：

我无法决定如何看待这段代码：

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

它是我当前项目中视图模型的一部分，您可以想象，Brush 将绑定到 UI 中的一些文本元素，以指示其他数据的（无效）有效性，在否则相当简单直接的对话。

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

反对者说这违反了关注点分离，因为它明确规定了应该由视图单独处理的样式。

请分享您的论点，如果您对上面的代码不满意，请分享您对替代解决方案的想法。（我对你对使用DataTemplates 的看法特别感兴趣）。

是否有一种解决方案可以被视为最佳实践？

【问题讨论】：

这和DataTemplates有什么关系？
@Reed Copsey：我的印象是使用映射到特定DataTypes 的DataTemplates 是解决问题的一种替代方法。我想知道它是否被使用，或者被认为太“重量级”。
使用DataTemplate 并不是处理笔刷更换的合适方式。它们实际上是用于确定如何显示自定义类型。例如，它们可用于将自定义类映射到旨在适当显示该类信息的视图。

标签： wpf xaml mvvm

【解决方案1】：

就个人而言，我会在 XAML 中定义两个画笔，并让使用它们的控件根据 IsValid 属性切换画笔（在 xaml 中）。这可以使用 DataTriggers 或什至单个 IValueConverter 轻松完成 - 转换器可以使用 2 个画笔和一个布尔值并相当容易地在它们之间进行交换。

这使业务逻辑呈现中性 - “画笔”非常特定于特定的呈现形式，并且是纯粹的视图选择。将其硬编码到 ViewModel 中违反了单一职责原则，也不是一个清晰的关注点分离。

我非常愿意将其保留在视图中，并根据特定于 ViewModel 的 IsValid（绑定）属性进行切换。

【讨论】：

说得好。如果您甚至会想到关于在何处定义画笔的“最佳实践”，答案是 DataTrigger/IValueConverter，而不是 ViewModel。

【解决方案2】：

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

更难改变。如果您将画笔定义为资源并在样式中使用它们，则更改应用程序的配色方案只需加载不同的资源字典即可。如果您在视图模型中对颜色值进行硬编码，如果最终用户需要不同的颜色，那么您需要更改很多不同的内容。
更难测试。如果你想编写一个单元测试来检查一个属性是否返回了正确的画笔，你必须在你的单元测试中创建一个画笔并比较两者的值，因为它是一个引用类型。
在许多甚至大多数情况下，它不会使代码更简单或更易于维护。您很可能已经在使用一种样式（假设您熟悉样式），因为它们使 WPF 中的几乎所有内容都变得更容易。将IsValid 绑定到画笔颜色只需在样式中添加DataTrigger。这是任何维护此代码的人都希望找到它的地方。

确实有时我确实在视图模型中使用 WPF 构造 - 例如，很久以前就不再怀疑如果视图模型暴露了 Visibility 类型的属性是否有问题。请注意，上述问题均不适用于该案例。

【讨论】：

【解决方案3】：

在像您这样纯粹出于美学考虑的情况下，我使用触发器或视觉状态管理器来更改颜色。

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

【讨论】：