我试图从最近的两个星期开始理解MVVM，但是在理解它时仍然有很多困惑。

我最近开始开发Windows Phone 8。

我对MVVM的了解，

M = Model是指数据，具体是说Model应该被视为C语言的结构。 它仅具有属性或成员变量(对象)。 它对视图和视图模型一无所知。

V =普通XAML。 绑定应该只有一种方式，那就是使用DataContext。

VM = View Model是用于视图的模型。 VM使用M保留其数据(使用Containership)，并且VM负责将数据保存在DB中或从db获取数据。 数据库交互应在VM中进行。 VM应该实现INotifyPropertyChanged，因为它负责保存和获取数据。

请提出关于MVVM的错误概念。

您所说的一切在技术上都是正确的，但我会尝试以一种更抽象的方式来处理设计模式，并考虑其要解决的问题。 MVVM正在尝试解决在视图和模型之间分离以及提供双向绑定的问题(即从模型中提取数据并呈现它，以及将用户输入并将其保存回模型中)。

大多数模式都希望将视图和模型分开，因此在MVVM中仍然是相同的，但是更模糊的是如何转换/格式化要显示给用户的数据，以及如何将用户输入转换为模型。在许多MVC框架中，视图中的模型数据表示都得到了很好的处理，但是您通常要自己承担用户输入并干净地转换回模型的责任。 MVVM旨在同时处理这两种情况。

Microsoft选择使用DependencyProperty，ICommand和ValueConverters之类的方法来执行此操作。基本思想是，您的View仅通过绑定松散地连接到ViewModel，因此从理论上讲，您可以将ViewModel与其他视图重用。这在另一个方向上是相同的(例如，这种清晰的双向绑定使MVVM与MVC有所不同)，因为您的VM可以通知属性已更改(这就是为什么必须实现INotifyPropertyChanged的原因)，但是VM具有不知道视图是否有反应。当您要重用这些组件时，这非常简单。

因此，了解MS正在尝试使用MVVM解决的问题，您可以希望更好地理解为什么存在诸如INotifyPropertyChanged之类的东西或ICommand的用途，并希望可以充分利用MVVM模式。

自2008年以来，我一直在使用MVVM，您的解释主要是因为我会向以前没有使用MVVM或任何MV *模式的人进行解释。

正如Michael所说，核心是将所有MV *框架所追求的观点与逻辑分开，但是在实现方法上却存在细微差异。使用WPF的XAML将数据绑定提升到了一个全新的高度，现在我们可以绑定几乎所有内容而无需直接依赖数据了。

在MVC中，我们有一个控制器"告诉"视图该做什么，而在MVVM中，该视图则侦听ViewModel必须说的话。 ViewModel的IsDirty属性指示数据已更改，然后视图具有可视化此方法。告诉视图要做什么不是ViewModels的工作，它是侦听ViewModel中的更改的视图。通过为输入控件绑定两种方式，这可以实现另一种方式。 ViewModel不知道此数据如何产生，它仅指示应为哪种类型。

当我试图解释用MVVM编写的更复杂的项目时，我将ViewModels分为两种不同的子类型。 WrapperViewModels，LogicViewModels。

• WrapperViewModel：这是一个ViewModel，或多或少只是一个模型的组成。它包含与PropertyChanged逻辑一起公开数据的属性。它包含用于公开例如的逻辑。当模型仅具有FirstName和LastName等时使用FullName。但是，可以通过在模型中实现INotifyPropertyChanged来替换此VM，但这可能不是所有情况下的最佳方法。

• LogicViewModel：这些VM是包含应用程序逻辑的VM。作为应用程序核心的MainViewModel是其中的一个示例。如果您将应用程序视为一组孤岛，其中每个孤岛负责应用程序的一部分，则此部分通常具有自己的LogicViewModel

当涉及到模型层时，我通常说以下逻辑驻留在该层中。数据，数据库访问，服务访问，文件访问。基本上，所有与应用程序外进出有关的代码。我不会在直接访问除模型对象和其他ViewModel之外的任何东西的ViewModel中编写任何逻辑。

在某些情况下，MVVM会使一些简单的任务变得过于复杂。在这些情况下，我建议考虑根据视图和视图模型进行实际控制。这样做可以重用控件并对其内部进行完全控制。简化MVVM开发并且几乎是强制性的其他方面是对Messenger /中介模式，依赖注入和行为/触发器/动作/附加属性的了解。

大多数人说的一件事是，View应该是纯Xaml，从来没有逻辑。我认为这是完全错误的。只要您遵循View不应该了解ViewModel逻辑的原则，View中就可以使用代码/逻辑。逻辑上纯粹是为了演示而进行日志记录就可以了，但是一旦您引用了ViewModel类，您将陷入困境。

我倾向于将MVVM描述为Model View Presenter的增长。在"模型视图演示者"中，演示者获取模型并构建视图。更改模型，视图也会更改。最简单的MVP，这就是为什么我要从它开始！

ViewModel替代了单向Presenter：它是一个状态跟踪双向等效项。除了监视模型的更改之外，它还监视事件和View的更改，并提供更新模型系统的粘合和逻辑。

这是从技术细节中删除的更通用的答案，并希望它在构思该想法方面做得很体面。