模型在MVVM中的作用

Question

我已经阅读了一些关于(数据)模型在MVVM模式中的作用的文章.但是,我仍然无法弄清楚模型中的内容.

该模型应该实现INotifyPropertyChanged吗？如果是这样,VM和模型之间有什么区别？

如果没有,模型中的更改将不会通知VM及其发生的视图.所以 - 考虑到逻辑进入模型,很明显它应该通知ViewModel它的一些变化.但是,在两个类中实现INotifyPropertyChanged并不奇怪吗？

非常感谢你!

Answer 1

该模型实现了您的业务逻辑.视图模型在视图(某种形式的UI,例如web,winform,CLI)中装饰您的业务逻辑,以便显示它并与之交互.所以,不,我不会说你的模型应该实现,INotifyPropertyChanged除非它作为你的核心业务逻辑的一部分.

@Horse,是的.我知道这需要更多的工作,但它确保了责任的明确分离,并最终使您的软件更易于测试.在我看来,这里的真正目标是确保您的业务逻辑在一个中心位置实现,即在模型中.请记住,各种视图模型可以使用相同的模型(例如web和winapp).因此,让视图直接与模型交互可能导致在模型中实现仅适用于一个视图的UI特定功能的必要性.视图模型的工作是避免这种情况. (3认同)
如果业务逻辑在模型中,那么它必须更改属性的值.您是否建议将事件从模型提升到viewmodel,以便VM进行更改？我试图找出如果逻辑在模型中,VM如何能够修改属性 (2认同)

Answer 2

您的一条评论:

对我来说这个模型实现了INotifyPropertyChanged似乎很奇怪,这在我看来是一个与UI相关的类

更改在各种上下文中使用的通知,而不是UI上下文.例如,您可能希望附加一段记录特定更改的诊断代码TextWriter.如果对象实现了更改通知,则无需修改底层模型对象即可轻松完成此操作.

但即使在仅用于更新UI的应用程序中,这种模式仍然有意义.因为通过事件处理更改通知,所以引发事件的对象与处理它的对象分离.您的模型不知道,也不需要知道哪种UI正在使用它.它只是说,"假设有一个用户界面,我需要告诉它,无论它是什么,这个属性的价值只是改变了."

那为什么会有一个视图模型呢？为什么不直接绑定到模型？实际上,如果它实现了更改通知,您可以直接绑定到模型.在许多简单的WPF应用程序中,不需要单独的视图模型 - 您可以在模型中实现更改通知并将其称为一天.当您需要将UI与基础业务逻辑分离时,您开始关注是否违反了单一责任原则,即需要出现视图模型.

Answer 3

在某些情况下,Model必须实现INotifyPropertyChanged.想象一下,您正在为ICQ编写客户端或类似的东西.ViewModel应该怎么知道,有人给你发了一条消息？

Model和ViewModel之间的区别:

ViewModel仅简化模型的输出.如果模型非常简单,则不需要ViewModel.