CODEWITHSUNDEEP
c#mvvm
Harald
Harald

Reputation: 325

MVVM – Correct implementation of the Model

The Context:
C#/WPF Windows-Store application using SQLite to store data locally with web access to download data.

The Application:
Data has to be downloaded from the web and mapped to a class which gets stored in a local SQLite database. For instance, in the Customer class: 

[Table("Customer")]
class Customer{
    [AutoIncrement, PrimaryKey, Unique]
    public int Id {get;set;} 
    public string Name {get; set;}
    …
}

The class gets manipulated by different threads, so INotifypropertyChanged in the Customer class is a bad idea. Furthermore, multiple Customers should be displayed by the GUI, thus the ViewModel contains a list of Customers. Additionally a Customer has to be extended by several properties to get displayed by the GUI correctly.

The Questions:
What is the Model? The Customer?
How should I extend the Customer with additional properties without messing up the Customer class?
Where should I but the business logic for storing Customers in the DB or downloading and mapping the data from the web to the Customer class? In the Model?
If your answer is the Customer is the Model and it shouldn’t include any logic, why does the MVVM pattern say the Model contains the business logic?

Upvotes: 2

Views: 544

Answers (2)

ΩmegaMan
ΩmegaMan

Reputation: 31616

What is the Model?

An entity or any class which holds / is the framework for data.

How should I extend the Customer with additional properties without messing up the Customer class?

Via the Partial class modifier. Allows you to place specialized logic into the extended operations/properties. Plus you can have customer adhere to INotifyProperty changed.

Where should I but the business logic for storing Customers in the DB or downloading and mapping the data from the web to the Customer class? In the Model?

Put all business logic in the ViewModel to acquire and store information. It is where the magic happens and is a conduit between the View and Models for the View to display.

why does the MVVM pattern say the Model contains the business logic?

Business logic is in the form of the entities which make up the data.

People new to MVVM get hung up on wondering about whether they are following MVVM properly or not. MVVM (IMHO) is just a three tiered data system (remember that paradigm) which separates data from the logic to get the data to ultimately displaying the data; the three tiers.

If one views MVVM as the old school three tiered data system where the VM contains/acquires the data (called the models) and processes the business logic to process the data and simply allows the View to display said data; it is as simple as that.

Upvotes: 0

Pajdziu
Pajdziu

Reputation: 920

The Customer is for sure the model in this case. A model should be POCO and every property used only by GUI should be in view model, for example CustomerViewModel.

The business logic should be in a model. Storing in a database could be resolved by using repository pattern.

A model usually have logic, but it's limited to business logic. According to MVVM you shouldn't put any UI logic in your model but rather in a view model.

Let's say we have your model

class Customer {
    public int Id { get; set; } 
    public string Name { get; set; }
}

and there is a need to show customer's name in uppercase. Rather then adding additional property to Customer class, you add one in view model

class CustomerViewModel implements INotifyPropertyChanged  {
    ...
    public string UpperCaseName { ... }
    ...
}

I think the Wikipedia page sums it up pretty good:

Model

Model refers either to a domain model, which represents the real state content (an object-oriented approach), or to the data access layer that represents that content (a data-centric approach).

View

As in the MVC and MVP patterns, the view is the user interface (UI).

View model

The view model is an abstraction of the view that exposes public properties and commands. Instead of the controller of the MVC pattern, or the presenter of the MVP pattern, MVVM has a binder. In the view model, this binder mediates communication between the view and the data binder. The view model has been described as a state of the data in the model.

Binder

Declarative data- and command-binding are implicit in the MVVM pattern. In the Microsoft solution stack, the binder is a markup language called XAML. The binder frees the developer from being obliged to write boiler-plate logic to synchronise the view model and view. When implemented outside of the Microsoft stack the presence of a declarative databinding technology is a key enabler of the pattern.

Upvotes: 3

Related Questions