Model-View-ViewModel(MVVM)模式的优点值得这些开销吗? [英] Are the advantages of Model-View-ViewModel (MVVM) pattern worth the overhead?

问题描述

该问题在本主题中提出:Model-View-ViewModel(MVVM)模式的优点值得承担这些开销吗?

The question is stated in the subject: are the advantages of Model-View-ViewModel (MVVM) pattern worth the overhead?

在许多情况下，实现视图模型会涉及复制Model属性以及有时在Model和ViewModel数据成员之间进行同步的相当大的开销.例如，当前在Silverlight 4&在WCF RIA中，不会生成视图模型(如果开发人员遵循MVVM模式，则由他来创建视图模型，通常会在ViewModel上复制相应模型的属性，除了将Model称为存储以外，其他操作没有什么意义).

In many cases, implementing the view model involves quite significant overhead of duplicating the Model properties and sometimes synchronization between Model and ViewModel data members. For example, currently in Silverlight 4 & WCF RIA, View Models are not generated (if the developer follows the MVVM pattern, it is up to him to create the view models, often duplicating the corresponding Model's properties at ViewModel, that do nothing significant but refer to Model as the storage).

为什么不扩展Model类，而提供其他属性以使其易于被View使用呢?

Why not extending the Model class, providing additional properties to make it easy to be consumed by the View instead?

推荐答案

为什么不扩展Model类，提供其他属性以使其更易于被View使用?

Why not extending the Model class, providing additional properties to make it easy to be consumed by the View instead?

在简单的情况下，这就是ViewModel的全部工作-封装Model，以使其可以由View使用的方式扩展.如果您的模型可以直接绑定，欢迎这样做.

In the simple cases, this is all the ViewModel is doing - wrapping up the Model so that its extended in a way that's consumable by the View. If your Model can be bound directly, you're welcome to do so.

话虽这么说，ViewModel层不只是包装模型而已-这也是应用程序特定逻辑的地方-即:应用程序的管道将发生.必须正确地提出来自Model类的请求，并将逻辑组合在一起.

That being said, there is more to the ViewModel layer than just wrapping the model - this is also where the application specific logic - ie: the application's plumbing, will occur. Something has to make the requests from the Model classes correctly and compose together the logic.

这篇关于Model-View-ViewModel(MVVM)模式的优点值得这些开销吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！