模型-视图-视图模型( Model-View-ViewModel，MVVM)模式的优势值得开销吗？

Question

问题是在主题中陈述的:模型-视图-视图模型(MVVM)模式的优势值得开销吗？

在许多情况下，实现视图模型涉及复制模型属性的相当大的开销，有时还涉及模型和ViewModel数据成员之间的同步。例如，目前在Silverlight4和WCF中，视图模型没有生成(如果开发人员遵循MVVM模式，则由他来创建视图模型，通常复制ViewModel中相应模型的属性，这些属性并不重要，只是将模型称为存储)。

为什么不扩展Model类，提供额外的属性，使其易于被View使用呢？

Answer 1

为什么不扩展模型类，提供额外的属性，使其更容易被视图使用呢？

实际上，这就是PresentationModel的作用。这是MVVM强有力的基础。不同之处在于ViewModel是视图的模型，而不是数据的模型。因此，您更关心视图如何处理数据。

如果您有一个简单的UI，它所做的全部工作就是呈现模型，那么我建议您在ViewModel的属性上公开该模型并绑定到该属性。确保模型确实实现了INotifyPropertyChanged等。

ViewModel的强大之处在于当您有事情要做时，以响应用户操作。然后，ViewModel可以支持命令，调用服务和验证，从而将模型保留为数据容器

Answer 2

为什么不扩展模型类，提供额外的属性，使其更容易被视图使用呢？

在简单的情况下，这就是ViewModel所做的一切--包装模型，使其以视图可使用的方式进行扩展。如果您的Model可以直接绑定，欢迎您这样做。

也就是说，ViewModel层不仅仅是包装模型--这也是特定于应用程序的逻辑--即:应用程序的管道将发生的地方。必须正确地发出来自模型类的请求，并将逻辑组合在一起。

Answer 3

如果你关心额外的工作，你总是可以创建一个ViewModelBase (INotifyPropertyChanged，错误/验证，泛型)来由你的ViewModel继承，它将最小化你认为可能花费时间进行复制的事情。此外，Silverlight/Wpf为我们提供了绑定，这大大减少了我们的编码，此外，XAML还通过标记提供功能来实现这一点。此外，您还可以通过使用屏幕、控制器等来进一步设计。

对我来说，我看不到使用MVVM有任何“开销”；如果有，那也是值得的。它恰当地处理了关注点的分离。它为开发提供了一个很好的平台，特别是在团队中，人们可以处理应用程序的不同方面，而不会影响其他团队成员的代码(特别是在开发人员和设计人员之间)。

希望这能有所帮助