MVC :: What is a model?

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.

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.

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