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

[英]Pros and cons of having a WPF specifics in the view model


I'm having trouble deciding what to think about this piece of code:

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

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

It is part of a view model in my current project and as you can imagine, the Brush will be bound to some text elements in the UI, to indicate (in-)validity of other pieces of data, in an otherwise fairly simple and straightforward dialog.

它是我当前项目中视图模型的一部分,正如您可以想象的那样,Brush将绑定到UI中的某些文本元素,以指示(in-)其他数据片段的有效性,否则相当简单明了对话。

The proponents of this piece of code say that since we're using WPF, we might as well allow for some simple WPF specific constructs in the view model.

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

The opponents say that this violates Separation of Concerns, as it clearly dictates style which should be taken care of solely by the view.

反对者说这违反了“关注点”,因为它明确规定了应该仅仅由观点来处理的风格。

Please share your arguments, and if you're not happy with the code above, please share your ideas around alternative solutions. (I'm particularly interested in what you have to say about using DataTemplates).

请分享您的论点,如果您对上述代码不满意,请分享您对其他解决方案的看法。 (我对你使用DataTemplates所说的话特别感兴趣)。

Is it possible that there is one solution that could be considered best practice?

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

3 个解决方案

#1


8  

Personally, I would have the two brushes be defined in XAML, and have the controls that use them switch brushes (in xaml) based on the IsValid property. This could be done very easily with DataTriggers, or even a single IValueConverter - the converter could take 2 brushes and a boolean and swap between them fairly easily.

就个人而言,我会在XAML中定义两个画笔,并使用它们的控件切换画笔(在xaml中)基于IsValid属性。这可以通过DataTriggers甚至单个IValueConverter非常容易地完成 - 转换器可以使用2个画笔和布尔值,并且相当容易地在它们之间交换。

This keeps the business logic presentation-neutral - a "Brush" is very specific to a specific form of presentation, and a pure View choice. Hard-coding this into the ViewModel violates the single responsibility principle as well as is not a clean separation of concerns.

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

I would very much keep this in the View, and switch based on the IsValid (bound) property that is ViewModel specific.

我非常希望将其保留在View中,并根据ViewModel特定的IsValid(bound)属性进行切换。

#2


2  

While there are circumstances where I might use WPF constructs in the view model, this isn't one of them. Here's why:

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

  • It's harder to change. If you define brushes as resources and use them in styles, changing your application's color scheme can simply be a matter of loading a different resource dictionary. If you hard-code color values in your view models, you have a lot of different things to change if it turns out your end users need different colors.

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

  • It's harder to test. If you want to write a unit test that checks to see if a property is returning the right brush, you have to create a brush in your unit test and compare the values of the two, since it's a reference type.

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

  • In many, maybe even most cases, it doesn't make the code simpler or easier to maintain. You're pretty likely to already be using a style (assuming that you are conversant with styles), since they make just about everything in WPF easier. Binding IsValid to brush colors is just a matter of adding a DataTrigger to a style. Which is where anyone maintaining this code would expect to find it.

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

There are certainly times when I do use WPF constructs in the view model - for instance, long ago stopped wondering if it was problem if a view model exposed a property of type Visibility. Note that none of the above concerns apply to that case.

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

#3


0  

In cases like yours where it's purely aesthetic I use Triggers or the Visual State Manager to change colors.

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

Sometimes I do use colors in my ViewModels, but only if its part of my software spec (e.g., the color of the chart displaying a patient's CO2 depends on localization). In that case, I use a Color struct bound property, allowing the View to use the Color for a SolidColorBrush, a GradientStop, or whatever it wants. I initially used a string in #AARRGGBB format to completely remove the WPF dependency but my more seasoned co-workers didn't like that.

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


注意!

本站翻译的文章,版权归属于本站,未经许可禁止转摘,转摘请注明本文地址:http://www.silva-art.net/blog/2011/02/02/6f97f82617b1e63f851803b2b461294f.html



 
© 2014-2019 ITdaan.com 粤ICP备14056181号