Play! Framework est novateur dans le sens où il ne respecte pas l’architecture des projets J2EE « classiques », souvent pour simplifier la vie du développeur. En plus de cela, il repose sur certaines conventions / nomenclatures (un peu comme Rails) qu’il faut connaître. Le fonctionnement est simple et souvent logique, il ne vous faudra pas longtemps pour comprendre le fonctionnement global d’une application développée avec Play.

Séparation de la présentation et de la donnée avec MVC (Model-View-Controller)

Play sépare votre application en plusieurs couches, reprenant le pattern d’architecture MVC.

• Le Model est un objet métier qui va être manipulé par votre application. Cela peut être un utilisateur, un rapport, un tweet, … Le Model ne doit pas être confondu avec ce que l’on nommé souvent un « Value Object » (VO). Un VO est une simple représentation de données (ensemble de propriétés), presque une ligne de votre base de données. Dans Play, un Model est un objet qui ajoute des méthodes spécifiques à votre objet métier. Par exemple dans un Model User, vous pourriez avoir une méthode qui calcule l’age de l’utilisateur, alors que vous avez comme donnée en BDD, sa date de naissance. De plus, le Model contient aussi la couche de « service » qui sert à accéder à la source de donnée. Pour récupérer un utilisateur, on va donc faire par exemple User.find(…), user.save(), user.delete(), … Grâce à JPA, la persistance se fait de manière transparente, vous n’aurez pas à vous en occuper
• La View qui effectue le rendu du Model, le plus souvent sous forme d’une interface utilisateur. Dans une aplplication Play, la vue est le plus souvent rendue en HTML / XML ou JSON
• Le Controller va prendre en charge les actions utilisateurs et va déclencher les modifications sur les Model. Le plus souvent, un Controller écoute une requête HTTP (une URL), extrait la donnée entrante (paramètres, headers), modifie le Model et demande le rendu d’une View (la page).

Dans une application Play, ces trois couches sont séparées dans des sous-dossiers de /app/. On retrouve donc dans ces dossiers:

• /app/controllers : Une classe Java par Controller. Chaque méthode public static de ce Controller est une « action », c’est-à-dire un point d’entrée dans votre code Java qui sera appelé lorsqu’une requête HTTP sera reçue par votre serveur.
• /app/models/ : Chaque Model est représenté par une classe Java, héritant le plus souvent de la classe « Model » de Play. Grâce à cet héritage, Play va vous offrir directement les méthodes de persistance de l’objet (save, delete, find, …). Vous y trouverez aussi des annotations JPA permettant de définir les contraintes de votre stockage comme les jointures / règles de validation
• /app/views/ : Le dossier views va contenir les templates Play. Ces derniers sont des fichiers HTML avec du Groovy (similaire à Java) permettant de réaliser des traitements sur la données entrante (conditions / boucles, …)

Cycle de vie d’une requête

C’est votre application Play qui va traiter les requêtes de A à Z. Voici le fonctionnement général:

1. Une requête HTTP est reçue par le framework
2. Le mécanisme de « routing » de Play va diriger cette requête vers le Controller le plus adapté (selon le paramétrage que vous avez réalisé dans vos fichiers de configuration).
3. Le Controller exécute la méthode correspondant à la requête (avec modification potentielle des Model
4. Le Controller demande le rendu d’un template (View) en lui injectant une ou plusieurs données (Model)
5. Le rendu final (souvent une page HTML) est renvoyé dans la réponse HTTP

Le « Router » que vous voyez dans ce schéma est en fait un simple fichier de configuration qui va lier vos URL à vos Controllers (points d’entrée). Nous allons voir le fonctionnement de ce fichier dans un prochain tutorial.