代码之家 › 专栏 › 技术社区 › Phil

MVVM和有状态命令-好还是坏主意?

cinch command mvvm wpf

Phil · 技术社区 · 15 年前

我想我会在这里发帖,希望拥有MVVM专业知识的人能够就以下是否是一个好主意发表意见:

我使用的是SachaBarber的CinchMVVM框架,其中包括Marlon Grech的SimpleCommand类。

这个类没有的一件事是文本属性,它通常用于将UI元素绑定到命令操作的“title”上。因此,我一直在编写这个类的扩展,它公开了一个文本属性。

现在,我遇到的是一个用例,在这个用例中,我使用一个命令来切换到设备的连接。我可以用很多不同的方法来实现这一点(不总是这样吗?这是软件!)。一种方法是从视图模型中公开多个命令对象-一个用于“断开连接”,另一个用于“连接”;让视图模型公开一个指示连接状态(isconnected)的属性,并使视图有条件地绑定到connect命令或disconnect命令。我对这个选择的反应是…讨厌!

我最初看到的不仅是提供一个文本属性,而且让命令对象实现inotifypropertieschanged,这样,ViewModel可以根据系统状态将文本属性动态更改为“connect”或“disconnect”。这样,我可以避免使用多个命令,只公开一个“ToggleConnection”命令对象。

不过,从这条路径开始,我突然想到,这种模式可能还有其他变化,因此需要根据命令状态更改UI。例如,除了根据连接状态更改命令的文本之外,还可以在需要根据连接状态更改图标的位置进行更改。因此,我开始编写一个“stateful”类,它实现了inotifyPropertyChanged,并公开了两个属性——“text”和“state”。我将类设为通用类,以便用户可以定义状态类型(我通常不喜欢在可避免的地方使用“object”)。

我的问题是…你认为这是个好主意还是坏主意?它可能偏离了命令的最初意图/设计;从我所看到的情况来看,通常情况下,命令对象是无状态的,因为它们是系统的“动词”。对于路由命令,如果我正确理解了事情,通常只期望命令的目标具有状态。特别是因为同一个命令可以路由到不同的处理程序,这取决于命令绑定的声明位置。

所以,我认为至少对于路由命令,状态是没有意义的。

但是,我不处理路由命令——我专门处理MVVM命令。在这种情况下,基本上没有命令的条件路由——MVVM视图直接绑定到特定的ViewModel的命令对象,它的Execute和CanExecute处理程序。

在这种情况下,它有意义吗?

我附上了一份相关代码的副本,以备使用/感兴趣。

谢谢, 菲尔

2 回复 | 直到 14 年前

Anderson Imes 15 年前

这真的取决于你认为什么更容易与之合作。

我个人并不简单地将.text属性放在命令上,因为这些命令没有重用性。这与框架中提供的routeDuiCommands(或类似的自定义静态命令)不同,因为它们在任何地方都被重用,“exit”的翻译如果要更改该命令,它将反映在整个应用程序中。在您的示例中,情况并非如此——所有操作都是一次性的。

在您的例子中,按钮文本的这个文本实际上是与您的命令分离的(即使其中一个影响另一个),所以最终分离它们可能会更容易,代码也会少一些,但是区别不会太大,最终会是一个比任何东西都更美味的问题。

我绝对同意你的两个命令-Blech。您编写的大多数按钮委托都必须以某种方式对状态做出响应(与您交谈的服务已关闭,如果用户选择此项等,则需要以这种方式填充此数据),因此我认为让委托适应ViewModel上的状态信息并不是错的。

总之,这有点冗长…带走的是“做任何感觉舒服的事”。

Jeremiah Morrill 15 年前

就像最后一张海报上说的,“任何感觉舒服的东西。”

在我的例子中,我通常使用 DelegateCommand . 如果我需要绑定到一些数据,我将绑定到VM。执行命令时,它在我的虚拟机中执行(通过在init时提供给delegate command的委托)。然后,执行的委托可能/可能不会运行一些可重用的代码来满足该命令。

听起来您想使用命令作为自己的虚拟机。我从来没想过在自己面前这么做,但如果你觉得很好,就去做吧!:)