MVVM 框架适合什么？
我知道 此 线程中引入的一些 Mvvm 框架，
请描述或给我链接那么它们有什么用呢？ 不是有关 MVVM 框架的有关 MVVM 的信息。 谢谢 ：） 我想知道： 什么是 MVVM 框架？
i know some Mvvm Frameworks that introduced in this thread
please describe or give me link for that what are them useful for?
not information about MVVM about MVVM Framework.
thanks :)
i want to know :
What Is MVVM Framework?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我认为你的问题不太准确。据我了解，你问的是各个框架的特点？！
您可以在此处<找到详细信息/a> 和此处。但是，您提到的线程中至少已经给出了其中一个链接...
编辑：
基本上，MVVM 框架是在利用 MVVM（模型-视图-视图模型）模式的应用程序中常用的类的集合。这可能包括在软件的独立部分之间进行通信的消息传递系统、依赖项注入技术、ViewModel 的基类、项目/类模板、验证机制、常用命令、显示对话框的技术等等......
要完全理解这样的框架，你必须先了解MVVM模式。因为只有那时（或者甚至只有在您完成第一个 MVVM 项目之后）您才会了解此模式的问题和/或挑战。
I think your question is not really precise. As far as I understand, you ask for the features of each framework?!
You can find detailed information here and here. However, at least one of these links has already been given in the thread you mentioned...
EDIT:
Basically, an MVVM framework is a collection of classes which are commonly used in applications utilising the MVVM (Model-View-ViewModel) pattern. This may include messaging systems to communicate between independent parts of a software, dependency injection techniques, base classes for ViewModels, project/class templates, validation mechanisms, commonly used commands, techniques for displaying dialog boxes, and so on...
To completely understand such a framework, you will have to understand the MVVM pattern first. Because only then (or even only after you did your first MVVM project) you will have an understanding of the problems and/or challenges of this pattern.
要使用 Mvvm 框架，只需按照以下步骤操作：
视图模型不应该是模型的包装器。视图模型的工作是代理对外部服务的请求，例如数据的加载和保存。数据本身以及验证和大部分业务逻辑都应该位于模型中。
我怎么强调都不为过。每当您创建一个通过委托包装模型的视图模型时，您就会在 API 中引入一个巨大的漏洞。特别是，任何直接引用模型的东西都可以更改属性，而视图模型和 UI 永远不会收到通知。同样，对模型中计算字段的任何更改都不会传播回视图模型。
理想情况下，视图模型与它们所使用的屏幕无关。在 WPF 应用程序中尤其如此，其中多个窗口可能共享视图模型的同一实例。
对于较小的应用程序，您可能只需要整个应用程序的单个视图模型。对于较大的应用程序，您可能需要一个用于主要功能，一个用于每个次要方面（例如配置管理）。
从绝对意义上讲，代码隐藏既不是好事也不是坏事。它只是放置特定于单个视图或控件的逻辑的地方。因此，当我看到根本没有隐藏代码的视图时，我立即检查是否存在以下错误：
MVVM Light 中的 EventToCommand 尤其糟糕，因为它会阻止控件在从屏幕上删除后被垃圾回收。
如果模型的生命周期比侦听其事件的视图模型更长，那么您可能会发生内存泄漏。与具有已卸载事件的视图不同，视图模型没有一个好的生命周期管理故事。因此，如果他们将一个事件附加到一个可能比他们更持久的模型上，那么视图模型就会被泄漏。
To use Mvvm framework just simply follow below steps:
View-models are not supposed to be wrappers around models. The job of a view-model is to broker requests for external services such as the loading and saving of data. The data itself, as well as validation and most of the business logic, should be in the models.
I can’t emphasize this enough. Whenever you create a view-model that wraps a model by delegation you introduce a huge hole in your API. Specially, anything with a direct reference to the model can change a property in such a way that the view-model and thus the UI are never notified. Likewise, any changes to calculated fields in the model won’t be propagated back to the view-model.
Ideally view-models are agnostic to the screens they are used by. This is especially true in a WPF application where multiple windows may be sharing the same instance of a view-model.
For smaller applications such you may only need a single view-model for the whole application. For larger applications you may need one for the main functionality and one for each secondary aspect such as configuration management.
In absolute terms code behind is neither a good nor a bad thing. It is merely a place to put logic that is specific to a single view or control. So when I see a view with no code-behind at all I immediately check for the following mistakes:
EventToCommand from MVVM Light is especially bad because it will prevent controls from being garbage collected after they are removed from the screen.
If a model has a longer life-span then the view-model that listens to its events then you probably have a memory leak. Unlike views which have an unloaded event, view-models don’t have a good story for life-cycle management. So if they attach an event to a model that may out-last them then the view-model will be leaked.