J'aime beaucoup écrire des logiciels et des méthodes de programmation basées sur la conception modulaire, mais je n'aime pas vraiment m'appuyer sur des progiciels et des bibliothèques tiers pour gérer certaines choses triviales, car ils ne le font pas. Ne laissez pas votre niveau de programmation être grandement amélioré. J'écris donc des logiciels basés sur des modules dans Laravel depuis deux ans et je suis très satisfait des résultats.
Le facteur décisif qui me pousse vers des logiciels et des méthodes de programmation basés sur la conception modulaire est que je souhaite continuer à améliorer mon niveau de programmation. Imaginez que vous construisez une structure de projet et que 6 mois plus tard vous découvrez que le projet comporte de nombreux bugs. L'architecture du projet n'est généralement pas facile à modifier sans affecter 6 mois de code existant. En analysant ce projet, j'ai remarqué deux points principaux : soit vous avez un standard tout au long du projet et vous vous y tenez, soit vous modularisez et améliorez module par module.
Certaines personnes ont tendance à se développer à tout prix et à s'en tenir à une norme, même si cela peut signifier adhérer à une norme qu'on n'aime plus. Personnellement, je préfère l'amélioration continue, et peu importe si le 20ème module est complètement différent du premier module. Si un jour j'ai besoin de revenir au module 1 pour corriger un bug ou refactoriser, je peux l'améliorer au dernier standard utilisé par le 20ème module.
Supposons que, comme moi, vous aimiez développer des applications Laravel basées sur la modularité et évitez autant que possible d'ajouter des dépendances tierces inutiles au projet - cet article est un peu de mon expérience.
1- Fournisseur de services de routage
Le système de routage Laravel peut être considéré comme l'entrée de toute l'application. La première chose à modifier est le fichier RouteServiceProvider.php par défaut, qui doit modulariser les routes existantes.
<?php namespace App\Providers; use Illuminate\Support\Facades\Route; use Illuminate\Foundation\Support\Providers\RouteServiceProvider as ServiceProvider; class RouteServiceProvider extends ServiceProvider { /** * 定义应用路由。 * * @return void */ public function map() { $this->mapModulesRoutes(); } protected function mapModulesRoutes() { // 如果你在编写传统 Web 应用而非 HTTP API,请使用 `web` 中间件。 Route::middleware('api') ->group(base_path('routes/modules.php')); } }
Comme ci-dessus, nous pouvons simplement nous débarrasser de l'intégralité du passe-partout de ce fichier et simplement configurer un fichier de routage modulaire.
2- Fichiers du module
Laravel est livré avec quelques fichiers dans le dossier routes. Puisque nous ne mappons plus ces itinéraires dans le RouteServiceProvider, nous pouvons les supprimer directement. Ensuite, nous créons un fichier de routage modules.php.
<?php use Illuminate\Support\Facades\Route; Route::group([], base_path('app/Modules/Books/routes.php')); Route::group([], base_path('app/Modules/Authors/routes.php'));
3- Module Livres
Dans le dossier de l'application, créez le fichier Modules/Books/routes.php. Dans ce fichier nous pouvons définir des règles de routage pour le module Livres de l'application.
<?php use App\Modules\Books\ListBooks; use Illuminate\Support\Facades\Route; Route::get('/books', ListBooks::class);
Vous pouvez utiliser le routage basé sur le contrôleur, qui est la méthode de routage standard par défaut dans Laravel, mais je préfère personnellement la méthode Au revoir les contrôleurs, bonjour les gestionnaires de requêtes (abandonner les contrôleurs et utiliser les gestionnaires de requêtes). Ce qui suit est l'implémentation de ListBooks.
<?php namespace App\Modules\Books; use App\Eloquent\Book; use App\Modules\Books\Resources\BookResource; class ListBooks { public function __invoke(Book $book) { return BookResource::collection($book->paginate()); } }
Dans le code ci-dessus, BookResource est la couche de conversion de ressources de Laravel. Suite à la recommandation officielle pour les espaces de noms, nous pouvons le créer dans le dossier app/Modules/Books/Resources.
<?php namespace App\Modules\Books\Resources; use Illuminate\Http\Resources\Json\Resource; class BookResource extends Resource { public function toArray($request) { return [ 'id' => $this->resource->id, 'title' => $this->resource->title, ]; } }
4- Module Auteurs
On peut également démarrer le module Auteurs via le fichier Routes.
<?php use App\Modules\Authors\ListAuthors; use Illuminate\Support\Facades\Route; Route::get('/authors', ListAuthors::class);
Remarque : L'espace de noms app/Modules/Authors représente les fichiers que nous écrivons et est très simple pour les gestionnaires de requêtes.
<?php namespace App\Modules\Authors; use App\Eloquent\Author; use App\Modules\Authors\Resources\AuthorResource; class ListAuthors { public function __invoke(Author $author) { return AuthorResource::collection($author->paginate()); } }
Enfin, nous convertissons la classe Resource écrite au format JSON réactif.
<?php namespace App\Modules\Authors\Resources; use App\Modules\Books\Resources\BookResource; use Illuminate\Http\Resources\Json\Resource; class AuthorResource extends Resource { public function toArray($request) { return [ 'id' => $this->resource->id, 'name' => $this->resource->name, 'books' => $this->whenLoaded('books', function () { return BookResource::collection($this->resource->books); }) ]; } }
Remarquez comment la ressource va dans un autre module pour réutiliser le BookResource . Ce n'est généralement pas un bon choix car les modules doivent être complètement autonomes et ne peuvent réutiliser que des classes standard telles que des modèles éloquents ou des composants génériques conçus pour être communs à n'importe quel module. La solution à ce problème consiste généralement à copier le BookResource dans le module Auteurs afin que les modifications puissent être apportées sans utiliser un autre module et vice versa. J'ai décidé de conserver cette utilisation entre modules, cet exemple montre une bonne règle empirique pour garder les modules isolés les uns des autres, mais si vous pensez que l'exemple ci-dessus est simple et ne posera probablement aucun problème. Assurez-vous toujours d'écrire des tests pour couvrir les fonctionnalités que vous écrivez afin d'éviter que d'autres personnes ne modifient votre application sans le savoir.
5- Conclusion
Bien qu'il s'agisse d'un exemple très simple, j'espère qu'il permettra aux gens d'exploiter facilement les normes structurelles du framework Laravel en fonction de leurs propres besoins. Vous pouvez modifier très facilement l'emplacement des fichiers afin de créer des applications modulaires. La plupart de mes projets sont livrés avec le module App/Components, qui peut être utilisé pour les classes de base génériques réutilisables pour n'importe quel module ; App/Eloquent, le dossier Modules peut être utilisé pour contenir des modèles Eloquent et des modèles relationnels de base de données dans lesquels nous pouvons créer n'importe quelle fonctionnalité basée sur sur la modularité. Voici la structure de répertoires de dossiers d'une application sur laquelle j'ai récemment commencé à travailler :
J'espère que tout le monde pourra en tirer ce concept, chaque module a ses propres besoins et peut avoir ses propres dossiers/entités/classes/méthodes/propriétés. Il n'est pas nécessaire de standardiser tous les modules exactement de la même manière, car certains modules sont beaucoup plus simples que d'autres et ne nécessitent pas de conception structurelle approfondie. Cet exemple montre le module AccountChurn fournissant l'API via un dossier HTTP tout en fournissant des commandes Artisan via la console. AccountOverview, en revanche, ne fournit que l'API HTTP et s'appuie sur des entrepôts, des objets de valeur (sacs) et des classes de service (paginateurs) pour fournir une plus grande valeur de données.
Tutoriels recommandés : "Tutoriel PHP" "Tutoriel 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!