L'utilisation de classes d'action dans la conception de l'architecture de programmation Laravel

Cet article vous présente principalement les informations pertinentes sur l'utilisation des classes d'action dans les idées de conception d'architecture de programme Laravel. L'article le présente en détail à travers un exemple de code. Il a une certaine valeur d'apprentissage de référence pour les études ou le travail de chacun. en avons besoin Apprenons avec l'éditeur ci-dessous

Avant-propos

Quand on parle d'architecture des applications, on demande souvent Venez à un classique question, c'est-à-dire "Où doit être placé ce code ?" Laravel étant un framework assez flexible, il n’est pas si simple de répondre à cette question. Dois-je écrire ma logique métier dans la couche Modèle, la couche Contrôleur ou ailleurs ?

Lorsque votre application ne dispose que d'un seul point d'accès, vous pouvez écrire une logique métier dans la couche Contrôleur. Mais aujourd’hui, une situation plus courante est qu’il existe de nombreux points d’accès pour appeler le même module fonction.

Par exemple, de nombreuses applications ont pour fonction d'enregistrer les utilisateurs. Le processus consiste à appeler un contrôleur et à renvoyer une vue indiquant si l'enregistrement a réussi ou échoué. Si cette application dispose également d'une version mobile, elle fournira probablement un ensemble d'API pour l'enregistrement des utilisateurs mobiles, car le format de données qu'elle doit renvoyer est JSON. Et il est également très courant d'utiliser la commande artisanale de Laravel pour créer des utilisateurs, en particulier au début du développement du projet.

Les deux morceaux de code ci-dessus peuvent ne pas sembler poser de problèmes, mais à mesure que la logique métier augmente, le code semblera très redondant. Par exemple, si vous devez ajouter la fonction d'envoi de notifications par e-mail aux utilisateurs après l'enregistrement de nouveaux utilisateurs, vous devez ajouter le code pour envoyer des e-mails aux deux contrôleurs ci-dessus. Mais si nous voulons garder le code simple et élégant, nous pouvons écrire cette logique métier ailleurs.

Quant à la question de savoir "où écrire le code de logique métier", vous pouvez obtenir une réponse commune dans n'importe quel forum, qui est "utiliser une couche de service, puis appeler cette classe de service dans la couche contrôleur" . Oui, c'est vrai, la question est de savoir comment concevoir la classe de service ? S'agit-il de créer une classe UserService pour implémenter toute la logique métier liée à l'utilisateur, puis d'injecter cette classe dans la couche Controller qui doit être utilisée ? Ou y a-t-il d'autres options ?

Évitez les pièges des classes divines

Tout d'abord, vous pouvez essayer de créer une seule classe pour un modèle spécifique qui contient tout le code. Par exemple :

semble parfait : nous pouvons déclarer ou utiliser des méthodes de création/suppression dans n'importe quel contrôleur et obtenir les résultats souhaités. Mais quel est le problème avec cette mise en œuvre ? Autrement dit, nous utilisons rarement un seul modèle dans le processus de résolution de problèmes.

Par exemple, lorsque nous créons un compte pour un utilisateur, nous devons également créer en même temps un blog séparé pour l'utilisateur. Si nous implémentons ce processus de la manière actuelle, nous devons créer une classe BlogService puis injecter ses dépendances dans la classe UserService.

Évidemment, à mesure que le secteur des applications se développe, il y aura des dizaines, voire des centaines de classes de services, dont certaines devront dépendre de 5 à 6 autres classes de services, le résultat final est la redondance du code et le chaos, et c’est une situation que nous voulons éviter à tout prix.

Présentation de la classe d'action unique

Ainsi, au lieu d'utiliser une seule classe de service avec plusieurs méthodes, nous avons décidé de la diviser en plusieurs A catégorie? Voici la méthode que j'ai utilisée dans chaque projet récent. Les résultats sont très bons et je la recommande à tout le monde.

Tout d'abord, abandonnons la terminologie trop générale et vague des services et jetons un coup d'œil à nos nouvelles classes d'action et définissons ce qu'elles sont et ce qu'elles peuvent faire.

• Une classe d'action doit avoir un nom qui décrit sa fonction, tel que : CreateOrder, ConfirmCheckout, DeleteProduct, AddProductToCart, etc.

• Il devrait avoir une et une seule méthode publique comme API. Idéalement, il devrait s'agir du même nom de méthode, comme handle() ou execute() . C'est très pratique si nous devons implémenter une sorte de modèle d'adaptateur pour nos classes d'action.

• Il doit être indépendant des demandes et des réponses. Il ne gère pas les demandes et n'envoie pas de réponses. Cette responsabilité devrait incomber au responsable du traitement.

• Cela peut dépendre d'autres classes d'action.

• Si quelque chose l'empêche d'exécuter et/ou de renvoyer la valeur attendue, alors il doit appliquer la logique métier appropriée en lançant une exception et laisser l'appelant (ou Laravel ExceptionHandler ) prendre la responsabilité pour savoir comment présenter/répondre aux exceptions.

Créez notre classe d'action CreateUser

Maintenant, prenons l'exemple précédent et refactorisons-le avec une seule classe d'action, que nous nommerons CreateUser .

Vous vous demandez peut-être pourquoi cette méthode lève une exception lorsque l'adresse e-mail est déjà occupée. N'est-ce pas garanti en demandant une vérification ? bien sûr. Cependant, ne serait-il pas préférable d'exécuter la logique métier à l'intérieur de la classe d'action ? Cela rend la logique plus facile à comprendre et à déboguer.

Examinons le code du contrôleur après avoir utilisé notre classe d'action, comme suit :

Maintenant, quelles que soient les modifications que nous apportons, l'utilisateur registres Le processus sera géré par des versions API et Web, élégantes et propres.

Imbrication de classes d'action

Supposons que nous ayons besoin d'une classe d'action pour importer 1000 utilisateurs dans notre application. Nous pouvons écrire une classe d'action et continuer à utiliser la classe CreateUser ci-dessus :

Plutôt sympa, n'est-ce pas ? Nous pouvons réutiliser le code CreateUser en l'intégrant dans la méthode Collection::map(), qui renvoie ensuite une collection de tous les utilisateurs nouvellement créés. Lorsque l'e-mail est occupé, nous pouvons renvoyer un objet nul ou l'enregistrer dans le fichier journal. Vous auriez dû y penser.

Décoration de classe d'action

Maintenant, supposons que nous souhaitions enregistrer chaque utilisateur nouvellement enregistré dans le journal. Nous pouvons écrire le code dans la classe d'action ou utiliser le modèle décorateur.

Nous pouvons ensuite utiliser le conteneur IoC de Laravel pour lier la classe LogCreateUser à la classe CreateUser, de sorte que chaque fois que nous avons besoin d'une instance de cette dernière, la première sera injectée :

AppServiceProvider.php

Cela rend plus pratique le contrôle de l'activation ou de la désactivation de la fonctionnalité de journalisation à l'aide de variables de configuration ou d'environnement :

AppServiceProvider.php

Résumé

L'utilisation de cette méthode semble nécessiter beaucoup de cours. Bien entendu, l’enregistrement des utilisateurs n’est qu’un exemple simple, conçu pour que le code reste court et clair. À mesure que la complexité du projet commence à croître, la valeur réelle des classes d'action devient de plus en plus évidente, car vous savez clairement où se trouve le code et ses limites.

Avantages de l'utilisation de classes à action unique :

• Un petit domaine logique unique peut empêcher la duplication de code et améliorer la réutilisabilité du code, tout en maintenant la stabilité.

• Facile à tester indépendamment pour différents scénarios.

• Les noms significatifs sont plus faciles à lire dans les grands projets.

• Facile à décorer.

• Cohérence dans l'ensemble du projet : empêchez la distribution du code entre les contrôleurs, les modèles, etc.

Bien sûr, cette méthode est basée sur une partie de mon expérience d'utilisation de Laravel au cours des dernières années et sur ma pratique dans certains projets. Cela a très bien fonctionné pour moi et maintenant je l'utilise même sur certains projets de petite et moyenne taille.

Si vous avez une approche différente, j'aurais vraiment hâte de la lire.

Ce qui précède représente l'intégralité du contenu de cet article. J'espère qu'il sera utile à l'étude de chacun. Pour plus de contenu connexe, veuillez faire attention au site Web PHP chinois !

Recommandations associées :

Le framework Laravel implémente l'utilisation d'un middleware pour la fonction de journalisation des opérations

Le framework Laravel implémente l'utilisation de auditeurs Effectuer la fonction d'enregistrement des instructions SQL

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!