wpf - 严格遵守 MVVM 模式?

标签 wpf mvvm

我是第一次构建 WPF 应用程序并使用 MVVM。总体而言,使用 MVVM 非常有趣,主要好处之一是 View 和模型类之间的良好分离。不要将它们混合在一起是一种纪律(至少是年轻的开发人员)。

我们有一个场景,需要在确认消息框后单击按钮关闭窗口。现在这可以通过处理按钮单击事件并在 Window 类本身中关闭窗口来实现旧方法。或者我们可以通过在 ViewModel 中创建命令、调用 Window 以显示消息框等来实现 MVVM 方式。

我明白这里需要做什么,但我的问题是 - 是否有必要在所有情况下都使用 MVVM 命令?是否存在我们不应该使用命令的异常(exception)情况,例如简单的用户界面操作?我们在这里没有过度使用 MVVM 吗?以 MVVM 方式做所有事情的好处到底是什么?

最佳答案

Or we can do it MVVM way by creating a command in ViewModel, call Window to show message box..etc.

让我把它分开,主要是因为 IMVHO 我一直看到这个做错了 - 很多人试图在 VM 中做太多事情。首先,问自己一个问题:

Is the prompt related to the data or business rules in any way whatsoever?

如果不是,即它只是一个“你真的确定吗?”输入提示符,那么这应该完全在 View 后面的代码中完成。 viewmodel 唯一需要知道或采取任何行动的时间是它实际上与 viewmodel 有关系时,在这种情况下,您应该从 VM 公开命令,但实际的窗口关闭仍然是从 View 背后的代码

VM 应该对它所绑定(bind)的 View 一无所知,这是 MVVM 模式的目的之一。它可以公开命令,但它不应知道用户已与特定 UI 元素1 交互,也不应直接知道窗口即将关闭。 VM 可以提示(通过对话服务,你确实有,是吗?)当前数据未保存,但它一般不知道窗口,因为它不知道它的数据是怎样的呈现。

有时您会走弯路,很容易过度分析某件事是应该纯粹从 View 、纯粹从 VM 还是两者结合来完成。如果您还记得 VM 的作用,并记住在 View 中隐藏代码是可以的(前提是它只做与 View 相关的事情并将 VM 的事情交给 VM),那么 99% 的时间您不会有问题。

1 例如,VM 不应该知道或关心用户是否只是单击了按钮、超链接或触摸了图像中的热点。可以使用相同的命令来处理其中的任何一个。

关于wpf - 严格遵守 MVVM 模式?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/9764774/

相关文章:

c# - 使用 MVVM 管理可取消的部分更新

wpf - MVVM、集合和 ORM

c# - DataContext 绑定(bind)和刷新

c# - 将 DataGrid 绑定(bind)到 ListBox 选定项

c# - 为什么 WhenAnyValue observable 会在订阅时触发?

MVVM 依赖注入(inject)跨平台

c# - System.Windows.MessageBox 在开始之前不会等待用户输入!

c# - 通过动画在 WPF ItemsControl 或 ScrollViewer 中循环项目?

wpf - 设置滚动条拇指大小

wpf - 优秀的开源 WPF 应用程序