*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. 

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)

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

 4. The **View** shows those changes