MVC :: What is a model?

Question

I am at a point where I must make a decision about models.

I am aware that models are what you use to do all your database manipulation.

But are models restricted to this?

By this I mean.

Are they meant only for database interaction, Or are they meant for all external data manipulation (e.g. data from external APIs etc)?

Answer 1

To me the simple explanation is:
View This is an entity that creates a request and receives the response and visualize the interface
Model This is an entity that receives the request of View and give the response back.
Controller This is the entity that sits in between view and model and co-ordinates them.

So from a system if you remove controllers and views what remains is Model.
So Model is not just data model or business logic model. It may also consists of the other parts like security, validation, processing, filtering etc.

Answer 2

For example, in Django, model is a class that maps to the data relation (table) and potentially bridge tables (e.g. for many to many relations).

The same class can have methods for the manipulations on the corresponding data, there could be additional classes that are not defining models by themselves, but the methods of accessing and filtering the data.

But term model in MVC does apply to describing data structures and the methods to access them in general.

The frameworks may be somewhat bending the abstract terminology. For example what Django calls views are actually controller functions, and the entities defining the presentation are called templates, instead of views.

Answer 3

Don't relate Model with just to database. Think of it as in-memory representation of your currently use data(for the data which is not currently in use, might be in DB and when you access that data, first it will come to Model and then propagate to other parts of the application.). When you done with your data manipulation(which you do in Model) you either save it to Database for some later use. Also, Model is the first class which gets the data filled from DB when you retrieve the data from DB.

Answer 4

The MVC paradigm is a design pattern where you organize your application in with the following structure.

The Model: this is where you should keep your data model, the algorithms. For example if you write a spreadsheet application, you would keep the data structure of your spreadsheet. You would have the computation engine in your model, you would have the code to save and load your spreadsheet in your model. These model class could potentially be reused in other applications, for example if you have code to do compression of data.

The View or views: these are the part of your code to visualize the data (the UI), for a spreadsheet you have a typical spreadsheet view with cells A1 to Z100 etc. You can also visualize your data using a chart view. Etc. A view could be reused in other application as well for example you could reuse your fancy chart view.

The controller is what connects the views to the model. This is probably the least reusable piece, the controller know about the model, know which views to displays. Typically the controller will setup the callback that the view will call when the user interact with the app. The controller will then get the information from the model and update the view.

If you follow these guidelines you might be able to change your model, for example change from a model that save files to a disk to a model that save files in the cloud without changing the UI... in theory. You could also be able to add new views without changing your model. You can also write unit tests or regression test for your models.

There is no strict rules, the best is to use common sense and your own judgment.

Answer 5

Updated/Rewritten

No they are not just restricted to database access.

In an MVC application the M will usually be the model of your domain. This means it can encapsulate business logic and data. I would suggest that you avoid an anaemic domain model. You can even setup your model to be persistence ignorant. To get an idea of what I mean have a look at this talk on Crafting Wicked Domain Models.

On the View and Controller side I'd recommend always using what's called a View Model, even when it feels like a 1 to 1 mapping. Sooner or later you'll find out the models are actually different and you don't want to give a View any more responsibility then translating a simple View Model directly into HTML or other rendering format.

The Controllers job is then to just execute behaviours on your Model and create View Models for the Views.