How to differentiate between Model and Entity?

Question

I have already read A LOT but I still struggle to understand the question of this post. I am building (learning how to build) my own web application using .Net Core Framework, and also I'm using MVVM architecture, and this terms are crucial for me to understand what I am doing, namely, the Entity Framework. If someone could explain them to me with some examples, it would be perfect. Thank you in advance guys.

Answer 1

There is a simple thing here.

A model is a model for a view etc. - they often contain only partial data compared to entities, data from multiple entities or additional fields that are just there to be output. I.e. a model may have a collection of possible values for another property so that the view can then show a dropdown to select a value.

An Entity (in Ef terminology) represents (simply said) data in a table or view (though they can be a little different). There is no concern about presentation here.

Answer 2

Within MVVM you have 3 components:

• the model
• the view (speaks for itself)
• the viewmodel

In entity framework, you have:

• entities

So how does it relates?

The Entity

In general it's "a thing" which has a right to exist. Within a EF context this is often referred to as a table.

ViewModel

It's a model, tailor made for a view. Ideally it contains a set of properties and some commands. Through binding, you can update your view by setting properties. The text of a label for example.

The Model

Now the fun starts; the Model is an object, possibly containing data and some of the business logic.

Basically, this could be an entity, but it doesn't necessarily have to be. As a matter in fact; depending on the size of your application don't (or do) want to mix your data layer with your business logic.

Wikipedia states it beautifully:

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

So, the entity can be your model, but in larger applications there is quite often a layer in between to separate the "business" language from the data layer language.

---

Note; if you put an API on top of things, you might also want to dig into the DTO.