What MVVM framework is Good For?

Question

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?

Answer 1

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.

Answer 2

To use Mvvm framework just simply follow below steps:

1. You have a model and a view-model with the same name.

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.

1. You have a view and a view-model with the same name.

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.

1. You have no code behind.

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:

• Does the view-model touch specific controls by name?
• Is the view-model being given access to controls via a command parameter?
• Is EventToCommand or another leaky behavior being used in place of simple event handler?

EventToCommand from MVVM Light is especially bad because it will prevent controls from being garbage collected after they are removed from the screen.

1. View-models are listening to property changed notifications

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.