= (meta)Data Model

Dans ce chapitre, nous allons parler de plusieurs concepts utiles au développement rapide d'une application.
Nous parlerons de modélisation, de métamodèle, de migrations, d'administration auto-générée, de traductions et de cycle de vie des données.

Django est un framework Web proposant une très bonne intégration des composants et une flexibilité bien pensée: chacun des composants permet de définir son contenu de manière poussée, en respectant des contraintes logiques et faciles à retenir.
Pour un néophyte, la courbe d'apprentissage sera relativement ardue; à côté de concepts clés de Django, il conviendra également d'assimiler correctement les structures de données du langage Python, le cycle de vie d'une requête HTTP

En restant dans les sentiers battus, votre projet suivra un dérivé du patron de conception `MVC` (Modèle-Vue-Controleur), où la variante concerne les termes utilisés: Django les nomme respectivement Modèle-Template-Vue et leur contexte d'utilisation.
Dans un *pattern* MVC classique, la traduction immédiate du **contrôleur** est une **vue**.
Et comme on le verra par la suite, la **vue** est en fait le **template**.

* Le modèle (`models.py`) fait le lien avec la base de données et permet de définir les champs et leur type à associer à une table. _Grosso modo_*, une table SQL correspondra à une classe d'un modèle Django.
* La vue (`views.py`), qui joue le rôle de contrôleur: _a priori_, tous les traitements, la récupération des données, etc. doit passer par ce composant et ne doit (pratiquement) pas être généré à la volée, directement à l'affichage d'une page. En d'autres mots, la vue sert de pont entre les données gérées par la base et l'interface utilisateur.
* Le template, qui s'occupe de la mise en forme: c'est le composant qui va s'occuper de transformer les données en un affichage compréhensible (avec l'aide du navigateur) pour l'utilisateur.

Pour reprendre une partie du schéma précédent, lorsqu'une requête est émise par un utilisateur, la première étape va consister à trouver une _route_ qui correspond à cette requête, c'est à dire à trouver la correspondance entre l'URL qui est demandée par l'utilisateur et la fonction du langage qui sera exécutée pour fournir le résultat attendu.
Cette fonction correspond au *contrôleur* et s'occupera de construire le *modèle* correspondant.

En simplifiant, Django suit bien le modèle MVC, et toutes ces étapes sont liées ensemble grâce aux différentes routes, définies dans les fichiers `urls.py`.

include::models.adoc[]

include::migrations.adoc[]

include::shell.adoc[]

include::admin.adoc[]

include::forms.adoc[]

include::auth.adoc[]

include::settings.adoc[]

include::tests.adoc[]

== Conclusions
