Analyse des Contrats dans le cadre Larave

Le contenu de cet article concerne l'analyse des contrats dans le cadre de Larave. Il a une certaine valeur de référence. Les amis dans le besoin peuvent s'y référer. J'espère qu'il vous sera utile.

Contrats

Les contrats de Laravel sont un ensemble d'interfaces qui définissent les services de base fournis par le framework, comme le contrat de garde utilisateur IllumninateContractsAuthGuard que nous avons vu dans le chapitre présentant l'utilisateur authentification Et le contrat utilisateur-fournisseur IlluminateContractsAuthUserProvider

et le contrat IlluminateContractsAuthAuthenticatable implémenté par le propre modèle AppUser du framework.

Pourquoi utiliser des contrats

A travers les fichiers de code source des contrats ci-dessus, nous pouvons voir que le contrat fourni par Laravel est un ensemble d'interfaces définies pour le module principal . Laravel fournit les classes d'implémentation correspondantes pour chaque contrat. Le tableau suivant répertorie les classes d'implémentation fournies par Laravel pour les trois contrats mentionnés ci-dessus.

契约	Laravel内核提供的实现类
IllumninateContractsAuthGuard	IlluminateAuthSessionGuard
IlluminateContractsAuthUserProvider	IlluminateAuthEloquentUserProvider
IlluminateContractsAuthAuthenticatable	IlluminateFoundationAuthAuthenticatable(User Model的父类)

Ainsi, dans un projet auto-développé, si le système d'authentification des utilisateurs fourni par Laravel ne peut pas répondre aux besoins, vous pouvez définir les classes d'implémentation du garde et du fournisseur d'utilisateurs en fonction des besoins. Par exemple, le projet sur lequel j'ai travaillé auparavant. était que l'authentification des utilisateurs reposait sur l'API du système de gestion des employés de l'entreprise, j'ai donc écrit moi-même les classes d'implémentation des contrats de garde et de fournisseur d'utilisateurs, permettant à Laravel de compléter l'authentification des utilisateurs via le Guard et le UserProvider personnalisés. Nous avons introduit la méthode de personnalisation de l'authentification des utilisateurs dans le chapitre présentant l'authentification des utilisateurs. Les lecteurs peuvent lire cet article.

Ainsi, le but de Laravel définissant des interfaces contractuelles pour toutes les fonctions principales est de permettre aux développeurs de définir leurs propres classes d'implémentation en fonction des besoins de leurs propres projets, et pour les consommateurs de ces interfaces (tels que : Contrôleur, ou le noyau fournit AuthManager, etc.) Ils n'ont pas besoin de se soucier de la façon dont les méthodes fournies par l'interface sont implémentées. Ils se soucient uniquement des fonctions que les méthodes d'interface peuvent fournir, puis utilisent ces fonctions. interface lorsque cela est nécessaire en fonction des besoins. Il n'est pas nécessaire d'apporter des modifications du côté du consommateur.

Définir et utiliser des contrats

Ce que nous avons mentionné ci-dessus sont tous les contrats fournis par le noyau Laravel Lors du développement de grands projets, nous pouvons également définir nous-mêmes le contrat dans le projet. et les classes d'implémentation. Vous pouvez penser que les couches Controller et Model intégrées sont suffisantes pour écrire du code. L'ajout de contrats et de classes d'implémentation supplémentaires à partir de rien rendra le développement fastidieux. Commençons par un exemple simple et considérons ce qui ne va pas avec le code suivant :

class OrderController extends Controller
{
    public function getUserOrders()
    {
        $orders= Order::where('user_id', '=', \Auth::user()->id)->get();
        return View::make('order.index', compact('orders'));
    }
}

Ce code est très simple, mais si nous voulons tester ce code, nous aurons certainement contact avec la base de données réelle. En d’autres termes, l’ORM et ce contrôleur sont étroitement couplés. Nous n'avons aucun moyen d'exécuter ou de tester ce code sans utiliser l'ORM Eloquent et sans nous connecter à une base de données réelle. Ce code viole également le principe de conception logicielle de « séparation des préoccupations ». En termes simples : ce contrôleur en sait trop. Le responsable du traitement n’a pas besoin de savoir d’où proviennent les données, mais simplement comment y accéder. Le contrôleur n'a pas besoin de savoir d'où proviennent les données MySQL, il a juste besoin de savoir que les données sont actuellement disponibles.

Séparation des préoccupations 　　　

Chaque classe devrait avoir une seule responsabilité, et cette responsabilité doit être entièrement encapsulée par la classe.

Chaque classe ne devrait avoir qu'une seule responsabilité Responsabilités, et tout dans les responsabilités doit être encapsulé par cette classe

Ensuite, nous définissons une interface, puis implémentons l'interface

interface OrderRepositoryInterface 
{
    public function userOrders(User $user);
}

class OrderRepository implements OrderRepositoryInterface
{
    public function userOrders(User $user)
    {
        Order::where('user_id', '=', $user->id)->get();
    }
}

Lions l'implémentation de l'interface au service de Laravel Dans le conteneur

App::singleton('OrderRepositoryInterface', 'OrderRespository');

🎜>

Ensuite nous injectons l'implémentation de cette interface dans notre contrôleur

class UserController extends Controller
{
    public function __construct(OrderRepositoryInterface $orderRepository)
    {
        $this->orders = $orderRespository;
    }
  
    public function getUserOrders()
    {
        $orders = $this->orders->userOrders();
        return View::make('order.index', compact('orders'));
    }
}

Désormais notre contrôleur est complètement indépendant du niveau des données. Ici nos données peuvent provenir de MySQL, MongoDB ou Redis. Notre contrôleur ne sait pas et n'a pas besoin de connaître la différence. De cette façon, nous pouvons tester la couche Web indépendamment de la couche de données, et il sera facile de changer d'implémentation de stockage à l'avenir.

Développement d'interface et d'équipe

Lorsque votre équipe développe une application volumineuse, différentes parties ont des vitesses de développement différentes. Par exemple, un développeur développe la couche de données et un autre développeur travaille sur la couche contrôleur. Le développeur qui a écrit le contrôleur souhaite tester son contrôleur, mais le développement de la couche de données est lent et ne peut pas être testé simultanément. Si deux développeurs parviennent d’abord à un accord sous la forme d’une interface, toutes les classes développées en arrière-plan suivront cet accord. Une fois qu'un contrat est établi, même si le contrat n'a pas encore été implémenté, les développeurs peuvent écrire une "fausse" implémentation pour cette interface

class DummyOrderRepository implements OrderRepositoryInterface 
{
    public function userOrders(User $user)
    {
        return collect(['Order 1', 'Order 2', 'Order 3']);
    }
}

Une fois la fausse implémentation écrite, elle peut être liée à l'IoC conteneur

App::singleton('OrderRepositoryInterface', 'DummyOrderRepository');

Les vues de l'application peuvent alors être remplies de fausses données. Ensuite, une fois que le développeur backend a fini d'écrire le véritable code d'implémentation, tel que RedisOrderRepository. Ensuite, en utilisant l'implémentation de l'interface de commutation de conteneur IoC, l'application peut facilement passer à l'implémentation réelle et l'ensemble de l'application utilisera les données lues à partir de Redis.

Interface et tests

Après avoir établi l'accord d'interface, il nous sera plus pratique de nous moquer pendant les tests

public function testIndexActionBindsUsersFromRepository()
{    
    // Arrange...
    $repository = Mockery::mock('OrderRepositoryInterface');
    $repository->shouldReceive('userOrders')->once()->andReturn(['order1', 'order2]);
    App::instance('OrderRepositoryInterface', $repository);
    // Act...
    $response  = $this->action('GET', 'OrderController@getUserOrders');
        
    // Assert...
    $this->assertResponseOk();
    $this->assertViewHas('order', ['order1', 'order2']);
 }

Résumé

Les interfaces sont très utiles dans la phase de programmation. Lors de la phase de conception, discutez avec l'équipe des interfaces à développer pour compléter la fonction, puis concevez les méthodes spécifiques à mettre en œuvre pour chacune. interface, les paramètres d'entrée et les valeurs de retour des méthodes, etc. Chacun peut développer son propre module selon l'accord d'interface. Lorsque vous rencontrez une interface qui n'a pas encore été implémentée, vous pouvez d'abord définir une fausse implémentation de l'interface et. Attendez que le développement réel de l'implémentation soit terminé avant de changer. Cela réduit non seulement la charge sur les couches supérieures de la structure du logiciel, mais le couplage de la couche inférieure peut également garantir que la progression du développement de chaque partie ne dépendra pas trop de la réalisation d'autres parties.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!