wpf - 关于 ViewModel 对简单状态的责任的 MVVM 设计选择

Question

我最近开始研究 MVVM 架构模式。我已经理解了其中的大部分内容，但对于 ViewModel 应该代表 View 承担多少责任 仍然没有什么疑问。

换句话说，View 应该有多笨？

例如，对于简单的状态协调，例如在用户按下 SubmitButton 后清除 TextView。这种状态协调只需要一行代码即可使用一些流行的数据绑定(bind)框架来实现。

例如在伪ReactiveCocoa :

textView.text <~ submitButton.pressed.map { _ in "" }

但是，Martin Fowler 在他的 Presentation Model 中写道,

The Presentation Model contains the logic that says that the composer field is only enabled if the check box is checked, so the when the view updates itself from the Presentation Model, the composer field control changes its enablement state

这表明即使是像在按下 Button 后清除 TextView 这样的简单逻辑也应该封装在 ViewModel 中。

这样的设计选择导致了这样的事情(同样，在伪 ReactiveCocoa 中):

// In View
viewModel.submitButtonPressed <~ submitButton.pressed
textView.text <~ viewModel.textViewText

// In ViewModel
textViewText <~ viewModel.submitButtonPressed.map { _ in "" }

虽然它会导致更好的逻辑封装，同时假设 View 只负责绑定(bind)(使其变得愚蠢)，但它确实会使代码更加冗长并导致 View 和 之间的耦合更紧密code>ViewModel(通过要求 ViewModel 了解 SubmitButton)。

总的来说，我对 MVVM 模式还是陌生的，每天都在学习东西。

ViewModel 应该承担多少责任？

换句话说，View 必须是完全愚蠢的并且只处理简单的绑定(bind)(将其 UI 元素连接到 ViewModel 提供的可绑定(bind)属性)或者 是否可以>View 来处理像上面这样的相当简单的逻辑？

附带说明一下，在 MVVM 中 View 和 ViewModel 之间是否紧密耦合 ok？

Answer 1

一般来说，ViewModel 承担所有责任。更具体地说，在您的场景中，ViewModel 不会知道 submitButton，但是 View 会知道 ViewModel 公开一个名为 SubmitCommand 的命令(一个 ICommand)，并将 submitButton 绑定(bind)到该命令。

有时，为了完全分离操作和相应的逻辑，可能会涉及更多，例如，当特定事件的命令没有可用的绑定(bind)时。但在那些情况下，一个相当简单的附加行为(即 InvokeCommandAction 和 friend ，请参阅 the documentation )可以弥合这一差距与同轴流，因此逻辑可以进入 ViewModel .

在极少数情况下(目前还没有想到)如此涉及到我只是跳过整个想法，并尽可能地分开，而不是必须三个月后弄清楚到底是怎么回事。但这些情况确实很少见。