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

Question

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

我正在使用 Sacha Barber 的 Cinch MVVM 框架，其中包括 Marlon Grech 的 SimpleCommand 类。

这个类没有其他替代品的一个属性是 Text 属性，它通常可用于将 UI 元素绑定(bind)到命令操作的“标题”。因此，我一直在为这个类编写一个扩展，它公开了一个 Text 属性。

现在，我遇到的是一个用例，我使用命令来切换与设备的连接。有很多不同的方法可以实现这个(并不总是存在 - 它是软件!)。一种方法是从我的 ViewModel 中公开多个命令对象——一个用于“断开连接”，一个用于“连接”；让 View 模型公开一个指示连接状态 (IsConnected) 的属性，并让 View 有条件地绑定(bind)到 Connect 命令或 Disconnect 命令。不过，我对这个选项的 react 是……糟糕!

我最初开始关注的不仅是提供一个 Text 属性，而且还让命令对象实现 INotifyPropertyChanged ，以便 View 模型可以根据系统状态将文本属性动态更改为“连接”或“断开连接”。这样做，我可以避免使用多个命令，而只公开一个“ToggleConnection”命令对象。

不过，从这条路开始，我突然想到，这种模式可能还有其他变体，因此 UI 需要根据命令状态进行更改。例如，除了根据连接状态更改命令的文本外，您可能还有一些地方需要根据连接状态更改图标。因此，我开始编写一个实现 INotifyPropertyChanged 的​​“有状态”类，并公开两个属性——“文本”和“状态”。我已将类设为通用类，以便用户可以定义 State 的类型(我通常不喜欢在可避免的情况下使用“对象”)。

我的问题是......你认为这是一个好主意还是坏主意？它可能与命令的初衷/设计有所不同；从我所看到的情况来看，一般来说，命令对象可能是无状态的，因为它们是系统的“动词”。使用路由命令，如果我理解正确，通常只期望命令的目标具有状态。特别是因为可以根据声明命令绑定(bind)的位置将相同的命令路由到不同的处理程序。

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

但是，我不是在处理路由命令——我是在专门处理 MVVM 命令。在这种情况下，基本上没有命令的条件路由 - MVVM View 直接绑定(bind)到特定 View 模型的命令对象，它是执行和可以执行的处理程序。

在这种情况下，这有意义吗？

我已附上相关代码的副本，以防它有用/感兴趣。

谢谢，
菲尔

Answer 1

这真的取决于你认为什么会更容易使用。

我个人不会将 .Text 属性放在我的命令上，因为我无法重用这些命令。它与框架中提供的 RoutedUICommands(或类似的自定义静态命令)不同，因为它们在任何地方都被重用，如果“退出”的翻译在该命令上发生更改，它将反射(reflect)在整个应用程序中。在您的示例中并非如此 - 一切都是一次性的。

在您的情况下，您的按钮文本的此文本确实与您的命令分离(即使一个会影响另一个)，因此最终可能会更容易并且将它们分离的代码更少，但差异不会这么多，它最终将成为一个比什么都重要的品味问题。

在 2 个命令的问题上，我绝对支持你 - blech。您编写的大多数按钮代表都必须以某种方式对状态使用react(您与之交谈的服务已关闭，如果用户选择了此数据，则需要以这种方式填充此数据，等等)，所以我真的不认为这是错误的委托(delegate)适应 ViewModel 上的状态信息。

无论如何，这有点罗嗦......外卖是“做任何感觉舒服的事”。