这是我的C＃项目的简短描述：
我有一个机械结构（在整个程序中只有一个），由大约20到30个参数（deimensions，材料参数等）描述，这些参数可以作为一个完整的集合来自输入屏幕或来自XML文件（反序列化）。然后必须在计算中处理这些参数以生成输出，该输出将转换为JPEG文件以及HTML文件。
视图很明确：它是IO屏幕。
View需要一个属性所在的ViewModel。也许：
我的模型是手头的结构，由参数描述。 但是，这些参数与从IO屏幕，视图或XML中收集的参数相同。
某些输出（JPEG文件）也会显示在View中。它可能是一个通知它已被更改的属性。
现在我的问题是，我是否需要一个模型，因为ViewModel已经具有所有属性。
或者，我是否需要ViewModel，因为我的模型具有要查看的所有属性。我可以在ViewModel中定义一个Model（就像它总是在MVVM中完成）并使用Model作为View的DataContext。但是最后一个选项会让View意识到模型：不是MVVM精神。
答案 0 :(得分：6)
我已经多次写过这个了，但我会再次这样做......
MVVM背后的主要原因是分离层并尽可能避免紧密耦合。
那就是说，View就像你正确猜到的那样，是UI。用户看到的东西。无论是Windows，页面，自定义控件，网页甚至是控制台（当我们在更广泛的背景下讨论MVVM时）都没关系。
ViewModel是模型和视图之间的中介。为了View的目的，它从模型中获取，组合和操作您的方法和属性。它并不关心这些使用的方式，时间和地点。它还可以触发模型端的操作，例如负责更新数据库的调用服务。
Model是与特定平台无关的一切。它是您的业务逻辑类，它是数据库实体等。它基本上是您的应用程序剥离了与UI实现的任何联系。这就是人们出错的地方，并认为模型只是数据库实体。那简直错了！
要回答您提出的问题：“现在我的问题是，我是否需要一个模型，因为ViewModel已经具有所有属性。”
是的，您应该，否则您最终会将视图直接耦合到模型，这违反了MVVM原则。您的视图不应直接了解该模型的任何内容。就View而言，每个属性和方法都可以来自不同的项目。它不会改变一个东西，视图仍然会起作用。
你可能还没有看到它，但将来它会让你的生活更轻松。如果正确完成，代码变得易于维护，更具可读性等。
答案 1 :(得分：0)
除了@walter所说的，你可以查看这个Codeproject条目，它可以完美地解释差异和更多一点。当我开始时，那篇文章帮助我解决了问题：
http://www.codeproject.com/Articles/100175/Model-View-ViewModel-MVVM-Explained
答案 2 :(得分：-1)
简而言之：
模型：表示数据的类，它不应该做任何事情。实施INotifyPropertyChanged是一种很好的做法，但如果您不需要从视图中更改数据，则不需要它。
ViewModel ：将模型公开为公共属性以便视图可以绑定到它的类。它应包含与模型交互的方法。它也可能包含它自己的属性。
查看：绑定到ViewModel，可以访问模型和ViewModel属性。