CODEWITHSUNDEEP
c#.netwpfmvvm
lysergic-acid
lysergic-acid

Reputation: 20050

MVVM and where to keep displayed fields/properties

I am learning MVVM by building a simple WPF calculator app.

In this simple app, there is one view (Main window), one ViewModel, and one Model (the calculation engine).

My calculator displays the current value of all previous operations, and the operations that got to that value.

For example a display might look like this:

1 * 2 * 3

    6

I am wondering if these should be saved as Properties on the ViewModel, Model, or both?

More general -- should the ViewModel contain only properties that exist on the Model, or this is not mandatory?

In this case i would save a CurrentValue and DisplayValue properties, just wondering which architecture layer should these belong to.

Upvotes: 0

Views: 515

Answers (5)

rio
rio

Reputation: 763

A model class is not only a business object, even if the model classes typically provide property and collection change notification events through change notification interfaces, so they can be data bound in the view, you can define an observable collection of instances of a class representing operations that represent he Ui interaction, so when a new op is inserted by the user, you add it to the collection and the UI will automatically reflect it through the binding to an templated listbox (for example)

Upvotes: 0

Nilesh Gule
Nilesh Gule

Reputation: 1621

ViewModel is specifically created for databinding purposes and as you expected contains properties needed by the view. In my opinion if you need any computed values to be displayed in the view, you can expose them as properties on view model.

Upvotes: 0

Haris Hasan
Haris Hasan

Reputation: 30097

I am wondering if these should be saved as Properties on the ViewModel, Model, or both?

In my opinion these should be property in ViewModel. Why these should be in the Model too? There is no benefit I can think of having this in Model too. These properties will only make sense to user in View so they should be displayed via ViewModel in the View. Model has nothing to do with it. At most you will have to pass expression 1 * 2 * 3 to Model and get results back, as you mentioned your engine is in Model.

More general -- should the ViewModel contain only properties that exist on the Model, or this is not mandatory?

In general, a ViewModel should contain all the properties that have to be displayed in the View (via ViewModel). Regardless of the fact whether this property exists in Model or not. There is no rule that if this exists in ViwModel it should must be in Model too and vice versa. Generally Model is nothing more than representation of your business entities.

Upvotes: 1

Pankaj Upadhyay
Pankaj Upadhyay

Reputation: 13584

In MVVM, ViewModels allow you to shape multiple entities from one or more data models or sources into a single object, optimized for consumption and rendering by the view. The below image illustrates the concept of a ViewModel:

enter image description here

The purpose of a ViewModel is for the view to have a single object to render, alleviating the need for UI logic code in the view that would otherwise be necessary. This means the only responsibility, or concern, of the view is to render that single ViewModel object, aiding in a cleaner separation of concerns (SoC). Concerns are distinct aspects of the application that have a particular purpose (i.e., concern), and keeping these aspects apart means your application is more organized, and the code more focused. Putting data manipulation code in its own location away from the view and controller, enforces SoC.

Using ViewModels in MVNM for finer granularity and better SoC leads to more easily maintainable and testable code. Remember, unit testing is about testing small units.

Upvotes: 4

Maxim V. Pavlov
Maxim V. Pavlov

Reputation: 10509

First of all, the model is not the place, where all your logic should be. The model is just the data for the view.

View model should contain any code needed to correctly adapt the model data to WPF display.

In your case you should work on an architecture a bit more.

There should be a class like CalculatorProcessor. View model may have properties for CurrentExpression, that, when a button = is pressed, are passed to a CalculatorProcessor to get processed (calculated) in sequece.

A result is also a property on a view model class that a view's controls are bound to.

Upvotes: 1

Related Questions