将Model与ViewModel分离的意义是什么?(MVVM)

3
我认为我没有正确理解MVVM模式,因为对我来说,拥有一个Model和ViewModel类似乎是多余的。
我的理解是,Model基本上是添加类的细节,让ViewModel处理所有逻辑和实现。如果是这样,为什么要将它们分开呢?你不能在视图模型中创建变量、属性等,并在其中保留逻辑吗?
对我来说,这听起来有点像C++。你有描述类的头文件和定义类的实现文件。在C#中这样做有什么意义吗?
我感觉我不理解分离的原因是我没有完全理解MVVM模式。如果有人能为我澄清一下,那就太好了。
提前致谢。

4个回答

5
为了让这个答案更具体,让我们看一个例子。你想在一个漂亮的WPF程序中使用同样的旧“计算器”示例。
不要急着进入并在视图模型中编写所有内容,你记得很久以前为另一个项目编写过此功能,并且足够聪明,将所有计算器功能放在单独的(可重复使用的)dll中。
现在只剩下你的GUI了。你在WPF中画了一个漂亮的窗口(视图),然后需要从dll到视图桥接你的调用和数据。你猜对了……这就是你的ViewModel :)。
另一方面,目的是能够在大团队中工作,其中一些人负责逻辑(model),一些设计师负责视图,而其他人(可以是任何上述人员之一)则通过视图模型将各种东西组合起来。

谢谢你的描述。那真的让一切都恍然大悟 :) - CodingMadeEasy
很高兴能够帮到你。第一次理解需要花费一些时间,但是一旦开始思考,通常会想要将类的职责解耦,因此开始将逻辑移动到可重用且易于测试的 dll 中,然后开始看到“模型”出现。 - Noctis

1

模型代表您的数据。视图模型仅使用这些模型来驱动您的用户界面。模型应该代表实体...事物。视图模型使用这些事物,这就是区别。


简单明了的答案。谢谢 :) - CodingMadeEasy

1
问题在于用户界面本身可以变得非常复杂。你会发现各种小部件 - 滑块、文本框、按钮、复选框、单选按钮 - 有时候视图不仅仅是“用这些模型的值填充这些空白”。ViewModel 是从UI角度对数据建模。通常情况下,这是对完整视图的简化,但它也可能是一种复杂化(例如,如果您有一个由存储在持久存储中的单个属性中的多个控件组成的聚合字段)。

1
在当前的分布式架构中,您的数据库(Model)和业务逻辑(VM)不必设计在同一物理系统上。因此,可能会通过某些服务(如WCF或WebApi)公开数据(Model),然后可以通过将相应的dll添加到项目中轻松地由VM消耗。
另一个重要的问题是,在UI上不需要显示数据库表的每一列。因此,通过具有Model,VM只会获取对终端用户在UI上必要的相关数据。

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接