Return to Answer

Okay, so I had it wrong. Updating...

Again, I had it wrong originally, updated, and still might contain stuff wrong, If someone can write a proper answer I'm all for it.

Okay, so I had it wrong. Updated:

THE MVC

• The Model is the background bussiness logic used to work with the data, it can contain the ORM model you have in your example many other things
• The Controller is the class doing something with The Model and producing Data Transfer Object or ViewModel and passing it to the View
• The View uses the Data Transfer Object/ViewModel to present itself

The MVVM

• The Model is the background business logic used to work with the data, it can contain the ORM model you have in your example (same as MVC)
• The ViewModel is the class doing something with The Model and populating data structures (properties) in itself. Then there is something listening (for simplification and because I'm lacking proper knowledge too, let's call it a view)
• The View reacts to the event, looks at the ViewModel property that changed, and draws/updates itself

I am not the greatest person to answer this as my knowledge is still lacking in many of the aspects, but I will try to give you a bit different perspective. So, when you receive a better answer from someone more knowledgeable you might want to listen to them :)

The MVC

The "MVC" in MVC means Model-View-Controller architecture.

It means that:

1. The Controller does something

2. During its work it produces a Model object

3. This Model object is given to a View

4. The View then uses the Model for presentation

Nowhere in there is there a need for the model to do anything on its own.

The model is what we call the object used to pass information between the controller and the view.

ORM Models

Also, the Model you're showing is an ORM (object-relational mapping) model - it is not the same model that we're talking about in the MVC.

In your case, it's an Entity Framework model (class) describing a table (or a part of a table) in the database.

It is used by the Entity Framework to represent the structure of a table in a database somewhere.

It (the class) allows the entity framework (and the controller using it) to either:

• create an entity (the object created using that class) and insert it into the table in the database

• search the table in the database and produce a collection of objects representing the rows of data in that table in the database

• Update existing row in a table in a database as specified by the difference in the values of the entity against the row

• Delete existing row in a table in a database based on the entity

Dangers of using ORM model as MVC model

The ORM model can be used as an MVC model (the object passed between the Controller and the View), but generally, I was always discouraged from doing so.

It is commonly used in simple or tutorial applications that way, as a proof of concept.

I was discouraged from doing so and am usually discouraging others unless the app is really simple or the risk of a malicious user is non-existent.

I am doing so because passing ORM models as MVC models introduces the potential for several problems like:

• the developer forgetting to properly sanitize the model or the controller code working with it and just passing the resulting object to a database and allowing the potentially malicious user to wreak havoc

• the Need to show processed output introducing complex code to the View

• the Need to show processed output introducing complex code to the ORM model itself in form of new properties or - god forbid - methods

If you have a large enough (or public-facing) application, you should separate your concerns.

You should let the Controller do its job and use the ORM to populate a proper Model containing only the things needed by the View and let the View decide how to show the data in the Model.

The View should not be filling/populating any data, the Model should be there to pass the data and the Controller is there to do the desired action and produce a model either by creating it or doing a magic trick and pulling it from a hat somewhere.

What about MVVM?

I also think you might be using the term MVC and mean MVVM (or MVB).

In MVVM, which means Model, View, ViewModel(Binder), the ViewModel(Binder) is responsible for populating itself and notifying the view of its changes.

In MVVM:

• The Model is the background data (so, for example, the data represented by the collection of objects described in the ORM classes)

1. The ViewModel (Binder) uses the Model to fill itself (doing the combined job of the Controller and the Model from the MVC)

2. The ViewModel (Binder) acts and notifies the View (using something, for example, an event) about the changes that happened inside itself

3. The View looks at the ViewModel (binder) and shows those changes

Okay, so I had it wrong. Updating...

1. The ViewModel (Binder) uses the Model to fill itself (doing the combined job of the Controller and the Model from the MVC)

2. The ViewModel (Binder) acts and notifies the View (using something, for example, an event) about the changes that happened inside itself

3. The View shows those changes

1. The ViewModel (Binder) uses the Model to fill itself (doing the combined job of the Controller and the Model from the MVC)

2. The ViewModel (Binder) acts and notifies the View (using something, for example, an event) about the changes that happened inside itself

3. The View looks at the ViewModel (binder) and shows those changes