Utilisation de l'injection de dépendance sur les façades laravel

Un problème avec les façades est que du code supplémentaire doit être écrit pour les prendre en charge lors des tests unitaires automatisés.

Quant aux solutions:

1. Résolution manuelle des dépendances

Une façon de résoudre les dépendances, si vous ne souhaitez pas le faire via. constructeurs ou méthodes d'injection, est d'appeler app () directement:

/* @var $email_services App\Contracts\EmailServicesContract
$email_services = app('App\Contracts\EmailServicesContract');

2. Refactoring

Parfois, quand je me retrouve à passer trop de services, ou de dépendances dans un classe, peut-être que J'ai violé la Responsabilité Unique Principe. Dans ces cas, peut-être qu'une nouvelle conception est nécessaire, en divisant le service ou la dépendance en classes plus petites. J'utiliserais un autre service pour envelopper un groupe de classes connexes pour servir quelque chose comme une façade. En substance, ce sera une hiérarchie de services / classes logiques.

Exemple: j'ai un service qui génère des produits recommandés et l'envoie aux utilisateurs par e-mail. J'appelle le service WeeklyRecommendationServices, et il prend 2 autres services comme dépendance - un Recommendation services qui est une boîte noire pour générer les recommandations (et il a ses propres dépendances - peut-être un repo pour les produits, un assistant ou deux), et un EmailService qui a peut-être Mailchimp comme dépendance). Certaines dépendances de niveau inférieur, telles que les redirections, les validateurs, etc. sera dans ces services à l'enfance au lieu du service qui agit comme le point d'entrée.

3. Utiliser les fonctions globales Laravel

Certaines façades sont disponibles en fonction appelle Laravel 5. Par exemple, vous pouvez utiliser redirect()->back() au lieu de Redirect::back(), comme view('some_blade) au lieu de View::make('some_blade'). Je crois que c'est la même chose pour dispatch et d'autres façades couramment utilisées.

(modifié pour ajouter) 4. Utilisation des traits Comme je travaillais sur des tâches en file d'attente aujourd'hui, j'observe également qu'une autre façon d'injecter des dépendances est d'utiliser des traits. Par exemple, le trait DispathcesJobs dans Laravel a les lignes suivantes:

   protected function dispatch($job)
    {
        return app('Illuminate\Contracts\Bus\Dispatcher')->dispatch($job);
    }

Toute classe qui utilise les traits aura accès à la méthode protégée et accès à la dépendance. Il est plus propre que d'avoir de nombreuses dépendances dans les signatures du constructeur ou de la méthode, est plus clair (sur les dépendances impliquées) que les globales et plus facile à personnaliser que les appels de conteneur DI manuels. L'inconvénient est que chaque fois que vous appelez la fonction, vous devez récupérer la dépendance du conteneur DI,

Méthodes de classe qui font partie du mécanisme de routage dans Laravel (middleware, contrôleurs, etc.) ont également leurs indices de type utilisés pour injecter des dépendances - ils n'ont pas tous besoin d'être injectés dans le constructeur. Cela peut aider à garder votre constructeur mince, même si Je ne suis familier avec aucune règle de limite de quatre paramètres; PSR-2 permet à la définition de la méthode d'être étirée sur plusieurs lignes probablement parce qu'il n'est pas rare d'exiger plus de quatre paramètre.

Dans votre exemple, vous pouvez injecter les services Request et Validator dans le constructeur en tant que compromis, car ils sont souvent utilisés par Plus d'une méthode.

Quant à l'établissement d'un consensus - Laravel devrait être plus opiniâtre pour que les applications soient suffisamment similaires pour utiliser une approche unique. Un appel plus facile cependant est que je pense que les façades iront dans le sens du dodo dans une future version.

Eh bien vos pensées et préoccupations et corriger et je les avais aussi bien. Il y a quelques avantages des façades ( Je ne les utilise généralement pas ), mais si vous utilisez juste, je suggère de les utiliser uniquement dans les contrôleurs, car les contrôleurs ne sont que des points d'entrée et de sortie pour moi au moins.

Pour l'exemple que vous avez donné, je vais montrer comment je le gère généralement:

// MyServiceInterface is binded using the laravel container
use Interfaces\MyServiceInterface;
use Illuminate\Http\Request;
use Illuminate\Validation\Factory as Validator;

...
class ExampleController {

    protected $request;

    public function __constructor(Request $request) {
        // Do this if all/most your methods need the Request
        $this->request = $request;
    }

    public function exampleController(MyServiceInterface $my_service, Validator $validator, $user_id) 
    { 
        // I do my validation inside the service I use,
        // the controller for me is just a funnel for sending the data
        // and returning response

        //now I call the service, that handle the "business"
        //he makes validation and fails if data is not valid
        //or continues to return the result

        try {
            $viewinfo = $my_service->getViewInfo($user_id);
            return view("some_view", ['view_info'=>$viewinfo]);
        } catch (ValidationException $ex) {
            return view("another_view", ['view_info'=>$viewinfo]);
        }
    }
}



class MyService implements MyServiceInterface {

    protected $validator;

    public function __constructor(Validator $validator) {
        $this->validator = $validator;
    }

    public function getViewInfo($user_id, $data) 
    { 

        $this->validator->validate($data, $rules);
        if  ($this->validator->fails()) {
            //this is not the exact syntax, but the idea is to throw an exception
            //with the errors inside
            throw new ValidationException($this->validator);
        }

        echo "doing stuff here with $data";
        return "magic";
    }
}

N'oubliez pas de casser votre code en petits morceaux individuels que chacun gère sa propre responsabilité. Lorsque vous correctement cassez votre code, dans la plupart des cas, vous n'aurez pas autant de paramètres de constructeur, et le code sera facilement testable et moqué.

Juste une dernière note, si vous construisez une petite application ou même une page dans une énorme application par exemple une "page de contact" et "page de contact submit" , vous pouvez sûrement tout faire dans le contrôleur avec des façades, cela dépend simplement de la complexité du projet.

J'adore le laravel en raison de sa belle architecture.Maintenant, à partir de mon approche, je n'injecterais pas toutes les façades dans la méthode du contrôleur seulement pourquoi? Injecter des façades de redirection uniquement dans les mauvaises pratiques du contrôleur comme il pourrait en avoir besoin dans d'autres. Et principalement les choses qui sont principalement utilisées devraient être déclarées pour tous tandis que pour ceux qui utilisent une partie ou seulement alors sa meilleure pratique pour les injecter via la méthode car lorsque vous déclarez en haut cela entravera l'optimisation de votre mémoire ainsi que la vitesse de votre code. J'espère que cela aiderait

Pas tellement une réponse mais un peu de matière à réflexion après avoir parlé à mes collègues qui ont fait quelques points très valables;

1. Si la structure interne de laravel est modifiée entre les versions (ce qui est arrivé dans le passé apparemment), l'injection des chemins de classe de façade résolus casserait tout sur une mise à niveau - tout en utilisant les façades par défaut et les méthodes d'assistance principalement (sinon complètement) évite ce problème.

2. Bien que le code de découplage soit généralement un bonne chose, la surcharge de l'injection de ces chemins de classe de façade résolus rend les classes encombrées - pour les développeurs prenant en charge le projet, Plus de temps est consacré à essayer de suivre le code qui pourrait être mieux dépensé pour corriger les bugs ou tester. Les nouveaux développeurs doivent se rappeler quelles classes injectées sont des développeurs et quelles sont les laravels. Les développeurs qui ne connaissent pas laravel sous le capot doivent passer du temps à chercher L'API. En fin de compte la probabilité d'introduire des bugs ou des fonctionnalités clés manquantes augmenter.

3. Le développement est ralenti et la testabilité n'est pas vraiment améliorée puisque les façades sont déjà testables. Le développement rapide est un point fort de l'utilisation de laravel en premier lieu. Le temps est toujours une contrainte.

4. La Plupart des autres projets, laravel façades. La plupart des personnes ayant de l'expérience en utilisant laravel utilisent des façades. Créer un projet qui ne suit pas les tendances existantes des projets précédents ralentit les choses en général. Futur inexpérimenté (ou paresseux!) les développeurs peuvent ignorer l'injection de façade et le projet peut se retrouver avec un format mixte. (Même les réviseurs de code sont humains)