Analyse du contrat Contracts dans le framework Laravel

Contrats

Les contrats de Laravel sont un ensemble d'interfaces qui définissent les services de base fournis par le framework. Par exemple, nous l'avons mentionné dans le. chapitre présentant l'authentification des utilisateurs Le contrat user watcher IllumninateContractsAuthGuard et le contrat user supplier IlluminateContractsAuthUserProvider ainsi que le contrat IlluminateContractsAuthAuthenticatable mis en œuvre par le modèle AppUser fourni avec le 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 de base. 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.

Ainsi, dans votre propre projet de développement, si le système d'authentification des utilisateurs fourni par Laravel ne peut pas répondre à vos besoins, vous pouvez définir les classes d'implémentation de l'observateur et du fournisseur d'utilisateurs en fonction de votre besoins, tels que 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 la classe d'implémentation du contrat de garde et de fournisseur d'utilisateurs, et j'ai laissé Laravel terminer l'authentification des utilisateurs via le Guard personnalisé et UserProvider. 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 les contrats 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 devons contacter 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 ».

Pour faire simple : ce contrôleur en sait trop.

Le responsable du traitement n'a pas besoin de savoir d'où proviennent les données, il a seulement besoin de savoir 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é devrait être entièrement encapsulée par la classe.

Chaque classe ne doit avoir qu'une seule responsabilité, et tout dans la responsabilité 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 du interface au conteneur de services de Laravel

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

Ensuite, nous injectons l'implémentation de l'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'));
    }
}

Maintenant, notre contrôleur est complètement indépendant de la couche de 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, différentes classes développées en arrière-plan suivront cet accord.

Une fois l'accord établi, même si l'accord n'a pas encore été mis en œuvre, le développeur peut é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é à

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

dans le conteneur IoC et la vue de cette application peut alors être remplie de fausses données. Ensuite, une fois que le développeur backend a fini d'écrire le code d'implémentation proprement dit, par exemple, il s'appelle RedisOrderRepository.

那么使用IoC容器切换接口实现，应用就可以轻易地切换到真正的实现上，整个应用就会使用从Redis读出来的数据了。

接口与测试

建立好接口约定后也更有利于我们在测试时进行Mock

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']);
 }

总结

接口在程序设计阶段非常有用，在设计阶段与团队讨论完成功能需要制定哪些接口，然后设计出每个接口具体要实现的方法，方法的入参和返回值这些，每个人就可以按照接口的约定来开发自己的模块，遇到还没实现的接口完全可以先定义接口的假实现等到真正的实现开发完成后再进行切换，这样既降低了软件程序结构中上层对下层的耦合也能保证各部分的开发进度不会过度依赖其他部分的完成情况。

更多laravel框架相关技术文章，请访问laravel教程栏目！

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!