Pourquoi utiliser le gestionnaire de services dans Zend Framework 2?

permet de dire que j'ai un service:

namespace Helloworld\Service;

class GreetingService
{
    public function getGreeting()
    {
        if(date("H") <= 11)
            return "Good morning, world!";
        else if (date("H") > 11 && date("H") < 17)
            return "Hello, world!";
        else
            return "Good evening, world!";
    }
}

et je créer un invokable pour elle

public function getServiceConfig()
{
    return array(
        'invokables' => array(
            'greetingService'
                => 'Helloworld\Service\GreetingService'
        )
    );
}

ensuite dans mon contrôleur je pouvais faire:

public function indexAction()
{
    $greetingSrv = $this->getServiceLocator()
        ->get('greetingService');

    return new ViewModel(
        array('greeting' => $greetingSrv->getGreeting())
    );
}

soi-disant ce faire, le contrôleur dépendant du service (et le ServiceManager)

et la meilleure solution est de créer une usine pour que le service ou le retour d'une fermeture dans le ServiceManager et de créer un setter dans le contrôleur:

class IndexController extends AbstractActionController
{
    private $greetingService;

    public function indexAction()
    {

        return new ViewModel(
            array(
                'greeting' => $this->greetingService->getGreeting()
            )
        );
    }

    public function setGreetingService($service)
    {
        $this->greetingService = $service;
    }
}

'controllers' => array(
    'factories' => array(
        'Helloworld\Controller\Index' => function($serviceLocator) {
            $ctr = new Helloworld\Controller\IndexController();

            $ctr->setGreetingService(
                $serviceLocator->getServiceLocator()
                    ->get('greetingService')
            );

            return $ctr;
        }
    )
)

Ma question est pourquoi? Pourquoi est la deuxième méthode est mieux que le premier? et que signifie le fait que le controller is dependent of the service?

grâce

source d'informationauteur Patrioticcow

12

La ServiceManager est par défaut injecté à l'intérieur de tout ZF2 contrôleur, comme elle s'étend de la AbstractController la mise en œuvre de la ServiceLocatorAwareInterface interface.

La deuxième approche a une forme de "la redondance" parce que, en plus d'avoir déjà accès à un ServiceManager exemple, si vous avez besoin de partager vos services auprès de vos contrôleurs, vous devez configurer pour chacun d'eux le mécanisme d'injection. Que vos contrôleurs ont déjà une dépendance vis-à-vis de l'ServiceManager, Il serait plus judicieux d'utiliser la première approche et enregistrez votre Domaine des Services liés à la ServiceManagercentralisant ainsi l'accès à la couche de Service.

_{Remarque: La partie suivante de la réponse peut aller au-delà de la portée de la question, mais il vise à fournir à l' "caché" de fond de l'original.}

Supposons que nous construisons un système complexe, dans lequel faible couplage, la ré-utilisabilité & test de capacité sont promus. Notre système est multi-couches et nous avons construit tout jusqu'à ce que la couche de service. Notez que jusqu'à maintenant, nous n'avons pas jugé pourtant, le "MVC" calque web ou même opter pour un cadre donné.

Au sein de notre Service de Couche (je vais envisager cette couche comme il est mentionné dans la question), nous supposons que nous avons adopté la principe de la séparation entre la Logique Métier et l'Objet Graphique de la construction (ou de la résolution des dépendances). Nous avons donc probablement un couple de services complexes qui sont construits par les usines.

Maintenant que notre service de couche est construite, nous décidons de nous "brancher" au-dessus de ZF2. Naturellement, Nos services doivent être accessibles à partir des contrôleurs, comme votre question illustré, nous avons plus qu'un moyen pour le faire. Cependant, nous voulons éviter la redondance et de tirer parti de ce que nous avons déjà construit. Supposons la suite d'usine :
```
//The following class is a part of our Service layer
public class ComplexServiceFactory{

    private dependencyA;
    private dependencyB;

    public function buildComplexService()
    {
        $service = new ComplexService();
        $service->setDependencyA($this->dependecyA);
        $service->setDependencyB($this->dependecyB);
        return $service;
    }

}
```
Ce que nous allons faire maintenant, c'est juste pour ajuster (étendre) notre usine de sorte qu'il devient utilisable par le ServiceManager logique. Cette classe peut être considérée comme faisant partie du mécanisme de "bouchon" de notre système de ZF2 (C'est en fait un Adaptateur)
```
public class SMComplexServiceFactory extends ComplexServiceFactory implements
    Zend\ServiceManager\FactoryInterface
{

    public function createService(ServiceLocatorInterface $sm)
    {
        $this->setDependencyA($sm->get('dependecyA'));
        $this->setDependencyB($sm->get('dependecyB'));
        return parent::buildComplexService;
    }

}
```
Ce faisant, nous ne sommes pas à l'éducation de l'objet graphique de la construction de la couche MVC (sinon, ce serait un La séparation des Préoccupations violation et inutile de la croix-couche de couplage). Le Gestionnaire de Services + nos "Adapté" fabriques de classes sont dans un certain sens, notre dépendance mécanisme de résolution. Le fait est que notre Système est encore portable, on peut par exemple opter pour un autre système (un autre cadre) et ont une faible dépendance vis-à-vis de la MVC plate-forme.
4

Très utile. Il a été soulevé à plusieurs reprises. Je pense que vous pouvez obtenir une RÉPONSE PRÉCISE à ICI
3

Ajouter quelque chose à l' @yechabbis réponse:

Le modèle de fabrique pour la ServiceConfiguration est en effet infrastructure complexe, ou tout simplement de ne pas utiliser closures /callable functions à l'intérieur de la configuration. C'est pour deux raisons:
- Lisibilité /Nettoyeur De Code
- Performance
De la configuration de l'usine de motif à l'intérieur de getServiceConfig est beau, propre et rapide. Pas de classes sont instanciées, mais le sera lors de l'appel du service-clé. Si, toutefois, vous pouvez configurer les services à l'aide de la fermeture de modèle ou de fonction appelable, ces classes seront toujours instancié, à chaque demande!

C'est probablement juste un exemple de chose, mais le code que vous avez montré permettrait également de mieux être servi comme un ViewHelper
0

Je pense que la deuxième approche est la meilleure, ce qui fait de la classe de contrôleur indépendant de la GreetingService. Cette approche sera utile lorsque vous voulez utiliser un autre service de voeux à être consommée par le contrôleur. Vous n'avez pas besoin de changer le code de la classe contrôleur à tous, au lieu de vous le faire en changeant le service gestionnaire de cette fermeture d'usine.

Je crois que c'est l'idée principale de l'inversion de contrôle ou de l'injection de dépendance, tout le câblage et la configuration sont effectuées à l'extérieur de la classe (dans ce cas: contrôleur de classe).

Donc, à mon avis, c'est la raison pour laquelle la deuxième approche est la meilleure.

Vous devez vous connecter pour publier un commentaire.