Tutoriel pour apprendre à utiliser le framework Laravel 5.3

Vous devez dans un premier temps avoir une base de données. Laravel permet de gérer les bases de type MySQL, Postgres, SQLite et SQL Server. Je ferai tous les exemples avec MySQL, mais le code sera aussi valable pour les autres types de bases.

Il faut indiquer où se trouve votre base, son nom, le nom de l'utilisateur, le mot de passe dans le fichier de configuration .env :

DB_CONNECTION=mysql
DB_HOST=127.0.0.1
DB_PORT=3306
DB_DATABASE=homestead
DB_USERNAME=homestead
DB_PASSWORD=secret

Ici nous avons les valeurs par défaut à l'installation de Laravel.

Voici par exemple mes réglages pour ma base de test MySQL nommée « tuto » avec MySQL en local non sécurisé :

DB_DATABASE=tuto
DB_USERNAME=root
DB_PASSWORD=

Nous avons déjà utilisé Artisan qui permet de faire beaucoup de choses, vous avez un aperçu des commandes en entrant :

php artisan

Vous avez une longue liste. Pour ce chapitre nous allons nous intéresser uniquement à celles qui concernent les migrations :

  Migrate              Run the database migrations
...
  migrate
  migrate:install      Create the migration repository
  migrate:refresh      Reset and re-run all migrations
  migrate:reset        Rollback all database migrations
  migrate:rollback     Rollback the last database migration
  migrate:status       Show the status of each migration

On va créer la migration pour notre table :

php artisan make:migration create_emails_table

Si vous regardez maintenant dans le dossier database/migrations, vous trouvez un fichier du genre 2016_08_31_212841_create_emails_table.php (la partie numérique qui inclut la date sera évidemment différente pour vous) :

Mais il y a déjà des migrations présentes, à quoi servent-elles ?

Il y a déjà effectivement deux migrations présentes :

• table users : c'est une migration de base pour créer une table des utilisateurs ;
• table password_resets : c'est une migration liée à la précédente qui permet de gérer le renouvellement des mots de passe en toute sécurité.

Nous nous intéresserons à ces migrations dans un chapitre ultérieur. Comme nous n'allons pas avoir besoin immédiatement de ces migrations, le mieux est de les supprimer pour le moment pour éviter de créer des tables inutiles :

Voici le contenu de la migration que nous venons de créer :

<?php
 
use Illuminate\Support\Facades\Schema;
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Database\Migrations\Migration;
 
class CreateEmailsTable extends Migration
{
    /**
     * Run the migrations.
     *
     * @return void
     */
    public function up()
    {
        //
    }
 
    /**
     * Reverse the migrations.
     *
     * @return void
     */
    public function down()
    {
        //
    }
}

On dispose dans cette classe de deux fonctions :

• up : ici on mettra le code de création ;
• down : ici on mettra le code de suppression.

On veut créer une table « emails » avec :

• un id autoincrémenté ;
• un champ « email » de type texte ;
• des champs pour mémoriser les dates de création et de modification.

Voilà le code correspondant :

public function up()
{
    Schema::create('emails', function(Blueprint $table) {
        $table->increments('id');
        $table->string('email');
        $table->timestamps();
    });
}

On demande au constructeur de schéma (Schema) de créer (create) la table « emails ». Dans la fonction anonyme, on définit ce qu'on veut pour la table :

• une colonne « id » auto-incrémentée qui sera ainsi la clé primaire de la table ;
• une colonne « email » de type string ;
• deux colonnes pour les dates (générées par la méthode timestamps).

Pour la méthode down on va juste supprimer la table avec un drop :

public function down()
{
    Schema::drop('emails');
}

Notre migration est maintenant créée.

On va maintenant utiliser la migration (méthode up de la migration) :

Si on regarde maintenant dans la base, on trouve la table « emails » avec ces quatre colonnes :

Vous avez aussi la création d'une table migrations :

Cette table sert à l'intendance des migrations et vous ne devez pas y toucher.

Si vous avez fait une erreur, vous pouvez revenir en arrière avec un rollback qui annule la dernière migration effectuée (utilisation de la méthode down de la migration) :

La table a maintenant été supprimée de la base. Comme on va avoir besoin de cette table, on relance la migration.

On peut aussi effectuer un rafraîchissement de toutes les migrations avec la commande refresh (rollback de toutes les migrations et nouveau lancement de toutes les migrations).

Vous disposez également de la commande status pour savoir où vous en êtes :

Mais pour le moment avec une seule migration, il n'y a vraiment pas de quoi se perdre.

On va avoir deux routes :

Route::get('email', 'EmailController@create'); 
Route::post('email', 'EmailController@store')->name('store.email');

Remarquez que la seconde route est nommée (store.email).

L'URL de base sera : http://monsite.fr/email

On crée le contrôleur avec Artisan :

php artisan make:controller EmailController

On le trouve dans son dossier :

Le code du contrôleur va reprendre l'essentiel de ce que nous avons vu dans les chapitres précédents en utilisant à nouveau la validation injectée. Modifiez ainsi le code :

<?php
 
namespace App\Http\Controllers;
 
use App\Email;
use App\Http\Requests\EmailRequest;
 
class EmailController extends Controller
{
    public function create()
    {
        return view('email');
    }
 
    public function store(EmailRequest $request)
    {
        $email = new Email;
        $email->email = $request->email;
        $email->save();
         
        return view('email_ok');
    }
}

La nouveauté réside uniquement dans l'utilisation du modèle :

$email = new Email;
$email->email = $request->email;
$email->save();

Ici on crée une nouvelle instance de Email. On affecte l'attribut email avec la valeur de l'entrée. Enfin on demande au modèle d'enregistrer cette ligne effectivement dans la table (save).

On ne se soucie pas des colonnes des dates (created_at et updated_at) qui sont automatiquement renseignées par Eloquent.

Dans ce cours je m'efforce de vous entraîner à prendre de bonnes habitudes. Plutôt que d'instancier directement une classe dans une autre, il vaut mieux une injection et laisser faire le conteneur. Regardez cette nouvelle version du contrôleur :

<?php
 
namespace App\Http\Controllers;
 
use App\Email;
use App\Http\Requests\EmailRequest;
 
class EmailController extends Controller
{
    public function create()
    {
        return view('email');
    }
 
    public function store(EmailRequest $request, Email $email)
    {
        $email->email = $request->email;
        $email->save();
         
        return view('email_ok');
    }
}

Maintenant le modèle est injecté dans la méthode, c'est plus élégant et efficace. Si jamais vous changez de modèle, vous n'avez plus qu'un changement de code limité sur le contrôleur. Mais ce n'est pas encore parfait.

Dans l'idéal on veut que notre contrôleur ne soit pas du tout concerné par un changement dans la gestion des modèles. Voici une façon de procéder :

<?php
 
namespace App\Http\Controllers;
 
use App\Http\Requests\EmailRequest;
use App\Repositories\EmailRepository;
 
class EmailController extends Controller
{
    public function create()
    {
        return view('email');
    }
 
    public function store(EmailRequest $request, EmailRepository $emailRepository)
    {
        $emailRepository->save($request->email);
         
        return view('email_ok');
    }
}

Maintenant j'injecte une classe de gestion qui possède la méthode save. Voici le contrat avec une interface (app/Repositories/EmailRepositoryInterface) :

<?php
 
namespace App\Repositories;
 
interface EmailRepositoryInterface
{
    public function save($mail);
}

Et voici la classe qui implémente cette interface (app/Repositories/EmailRepository) :

<?php
 
namespace App\Repositories;
 
use App\Email;
 
class EmailRepository implements EmailRepositoryInterface
{
    protected $email;
 
    public function __construct(Email $email)
    {
        $this->email = $email;
    }
 
    public function save($mail)
    {
        $this->email->email = $mail;
        $this->email->save();
    }
}

Le modèle est injecté dans cette classe. Je l'ai injecté dans le constructeur pour généraliser la démarche en imaginant qu'on créera d'autres méthodes que l'on peut regrouper ici pour gérer les enregistrements. Le code est maintenant parfaitement organisé, facile à modifier et à tester.

Le Design Pattern Repository est un des plus répandus. Il permet de gérer la persistance des informations.

On peut enfin, comme on l'a déjà vu, référencer l'interface plutôt que la classe, mais dans ce cas il faut informer le conteneur de la dépendance. Modifiez ainsi le fichier app/Http/Providers/AppServiceProvider.php :

public function register()
{
    $this->app->bind(
        'App\Repositories\EmailRepositoryInterface', 
        'App\Repositories\EmailRepository'
    );
}

Et le contrôleur :

<?php
 
namespace App\Http\Controllers;
 
use App\Http\Requests\EmailRequest;
use App\Repositories\EmailRepositoryInterface;
 
class EmailController extends Controller
{
    public function create()
    {
        return view('email');
    }
 
    public function store(EmailRequest $request, EmailRepositoryInterface $emailRepository)
    {
        $emailRepository->save($request->email);
         
        return view('email_ok');
    }
}

Maintenant, étant donné que le conteneur sait quelle classe instancier à partir de l'interface passée en paramètre, vous avez un code propre et facile à maintenir et à tester. Si vous changez d'avis sur la manière de stocker les emails, il vous suffit de décider d'instancier une autre classe à partir de l'interface, tant que le contrat passé avec le contrôleur ne change pas !