Zend FR

Salut Benjamin,

Qu'entends tu par "service" ?

Je vous propose une première implémentation de ce que je propose.

=========================================================

Les services s'ajoutent dans application.ini:

;====== Resource service (Service Layer)
resources.service.services.test-service.id = "testService"                  
resources.service.services.test-service.property = "testService"            ; nom de la propriété dans le controlleur
resources.service.services.test-service.className = "Service_TestService"

=========================================================

Tight_Service
Classe qui sert de container de services (plus ou moins un catalogue) et qui peut être alimenté.

<?php
/**
* Service Layer Pattern implementation
* 
* Define a service container to store
* all available services through application 
*
* @category Tight
* @package Tight_Service
* @author    Benjamin Dulau
*/
class Tight_Service 
{
    
    /**
     * Array of registered services
     *
     * @var array
     */
    protected $_services = array();

    
    public function __construct() {

    }    

    /**
     * Add a service to the services container     
     *
     * @param  array  $service config array for provided service     
     * @return void
     */
    public function addService(array $service = null) {
                
        if (is_array($service) && isset($service['id'])) {                    
            if (!array_key_exists($service['id'], $this->_services)) {
                                
                if (!isset($service['property']) || empty($service['property'])) {
                    throw new Tight_Exception_Service($service['property'] . Tight_Exception_Service::SERVICE_PROPERTY_NEED);
                    return;            
                } 
                                
                if (!isset($service['className']) || !class_exists($service['className'])) {
                    throw new Tight_Exception_Service($service['className'] . Tight_Exception_Service::SERVICE_CLASS_UNDEFINED);
                    return;
                }                                
                                
                $this->_services[$service['id']] = array(
                    'property'  => $service['property'],
                    'className' => $service['className']
                );
            }
        }        
    }
    
    /**
     * Return services list array
     * 
     * @return array
     */
    public function getServices() {
        
        return $this->_services;
        
    }
}

=========================================================

Tight_Service_Service
Classe qui définit un composant de service (un service), pourrait être étoffée, pourrait devenir une interface, je n'ai pas encore réfléchi à une composition précise et universelle d'un service.

<?php
/**
 * Tight_Service_Service
 * Service component
 * 
 * @category   Tight
 * @package    Tight_Service
 * @subpackage Service
 * @author     Benjamin Dulau
 */
class Tight_Service_Service 
{}

=========================================================

Tight_Application_Resource_Service
Ensuite, j'ai créé une classe de resource qui va initialiser mes services:

<?php
/**
 * Service resource
 *
 * @category   Tight
 * @package    Tight_Application
 * @subpackage Resource
 * @author     Benjamin Dulau
 */
class Tight_Application_Resource_Service extends Zend_Application_Resource_ResourceAbstract
{
    /**
     * @var Tight_Service
     */
    protected $_service;
    
    protected $_options = array();

    /**
     * Initialize Service
     * 
     * @return Tight_Service
     */
    public function init() {
        $service = $this->getService();
        
        // TODO: voir si options possibles pour les services
        $this->_options = $this->getOptions();

        if (is_array($this->_options['services'])) {
            foreach($this->_options['services'] as $svc) {
                   $this->_service->addService($svc);
            }
        }

        // TODO: paramétrage de cette partie pour plus de souplesse et
        // ne pas imposer un helper ? 
        Zend_Controller_Action_HelperBroker::addHelper(new Tight_Controller_Action_Helper_Service());

        return $service;
    }

    /**
     * Retrieve Service instance
     * 
     * @return Tight_Service
     */
    public function getService() {
        if (null === $this->_service) {
            $this->_service = new Tight_Service();
        }
        return $this->_service;
    }
}

=========================================================

Tight_Application_Resource_Service

<?php
/**
 * Provide IOC for services into Controller_Action
 *
 * @uses       Zend_Controller_Action_Helper_Abstract
 * @category   Tight
 * @package    Tight_Controller
 * @author       Benjamin Dulau
 */
class Tight_Controller_Action_Helper_Service extends Zend_Controller_Action_Helper_Abstract 
{          
    // TODO: Option pour activer/désactiver les services et ne pas
    // effectuer le traitement quand ce n'est pas nécessaire
    
    public function init() {                
        $bootstrap = Zend_Controller_Front::getInstance()->getParam('bootstrap');
        $serviceResource = $bootstrap->getResource('Service');
        $services = $serviceResource->getServices();
        
        $service = null;
        foreach($services as $svc) {            
            $var = '_' . $svc['property'];
            $class = $svc['className'];
            $setter = 'set' . ucfirst($svc['property']);
            
            // TODO: return false on protected or private properties
            // Fixed into PHP5.3
            if (property_exists($this->_actionController, $var)) {
                $service = new $class();
                if (!method_exists($this->_actionController, $setter)) {
                    throw new Tight_Exception_Service($setter . Tight_Exception_Service::SERVICE_SETTER_UNDEFINED);
                    return;
                }
                $this->_actionController->$setter($service);
            }
        }              
    }
}

=========================================================

Tight_Exception_Service

<?php
/**
 * Tight Service Exception
 * 
 * @see  Tight_Exception
 * @author Benjamin Dulau
 */
class Tight_Exception_Service extends Tight_Exception
{
    
    const SERVICE_PROPERTY_NEED     =  'Service provided must define a property to use into dependent classes.';
    const SERVICE_CLASS_UNDEFINED   =  'Provided service class doesn\'t exist.';
    const SERVICE_SETTER_UNDEFINED  =  'Property service setter undefined or cannot be found into dependent class.';    
    
}

=========================================================

UTILISATION :

application.ini :

;====== Resource service (Service Layer)
resources.service.services.test-service.id = "testService"                  
resources.service.services.test-service.property = "testService"            ; nom de la propriété dans le controlleur
resources.service.services.test-service.className = "Service_TestService"

Service :
Les classes de services doivent se trouver dans le dossiers "services" de chaque module (de même que pour models). Le ZF a déjà prévu dans l'autoloader ce type de ressources.

<?php 
class Service_TestService extends Tight_Service_Service {    

    public function test() {
        echo 'hello world';
    }    

}

Controlleur :

<?php
class IndexController extends Zend_Controller_Action
{        
    /**
     * @var Service_TestService
     */
    protected $_testService;
        
    public function setTestService(Service_TestService $testService) {
        $this->_testService = $testService;
    }

    
    public function indexAction() {        
        $this->_testService->test();        
    }
}

=========================================================

REMARQUES :

Voilà donc une première implémentation pour représenter ce à quoi je pense. On a donc un gestionnaire de services, des services indépendants, et un automatisme avec injection de dépendances dans les controlleurs.

Et en plus on conserve l'auto-completion sur les services dans les controlleurs.

Il reste pas de mal de choses à voir ou à repenser, déjà quelques problèmes/idées :

- option pour activer/désactiver le traitement quand les services ne sont pas utilisés dans les controlleurs;
- problème lié à property_exists() qui ne fonctionne pas pour les propriétés sur les types static, protected et private. Ce bug est corrigé dans PHP5.3, mais je cherche une méthode propre pour rendre ce code compatible pour les versions inférieures;
- agrémenter le conteneur (gestionnaire) de services pour lui apporter des méthodes pratiques. Par ex. pour accéder au catalogue des services enregistrés;
- définir un service générique sous forme d'interface ou de classe abstraite pourquoi pas pour avoir un point de départ et une implémentation cohérente de tous les services;
- et certainement plein d'autres choses ! :p


Voilà, balancez les critiques !!


A+ benjamin.

Dernière modification par Delprog (29-07-2009 12:12:48)

Mise à jour du helper:

<?php
/**
 * Provide IOC for services into Controller_Action
 *
 * @uses       Zend_Controller_Action_Helper_Abstract
 * @category   Tight
 * @package    Tight_Controller
 * @author       Benjamin Dulau
 */
class Tight_Controller_Action_Helper_Service extends Zend_Controller_Action_Helper_Abstract 
{          
    /**
     * @var bool
     */
    protected $_enabled = false;
    
    /**
     * If enabled by the action controller:
     * Browse registered services from Service application resource
     * and inject service components instances into action controller
     * properties provided for this purpose.
     */
    public function preDispatch()
    {                
        if ($this->_enabled) {
            $bootstrap = Zend_Controller_Front::getInstance()->getParam('bootstrap');
            $serviceResource = $bootstrap->getResource('Service');
            $services = $serviceResource->getServices();
            
            $service = null;
            foreach($services as $svc) {            
                $var = '_' . $svc['property'];
                $class = $svc['className'];
                $setter = 'set' . ucfirst($svc['property']);
                
                // TODO: return false on protected or private properties
                // Fixed into PHP5.3
                if (property_exists($this->_actionController, $var)) {
                    $service = new $class();
                    if (!method_exists($this->_actionController, $setter)) {
                        throw new Tight_Exception_Service($setter . Tight_Exception_Service::SERVICE_SETTER_UNDEFINED);
                        return;
                    }
                    $this->_actionController->$setter($service);
                }
            }    
        }          
    }
    
    /**
     * Enable services and IOC
     * To be called by action controllers
     */
    public function enable()
    {        
        $this->_enabled = true;
    }
}

Les controlleurs qui consomment des services doivent maintenant activer le système grâce à:

public function init()
{
    // enable services injections for this action controller    
    $this->_helper->service->enable();
}

A+ benjamin.

Tient marrant, on en parlait l'autre jour au boulot. Zend_Di avait été développé pour faire ça et finalement jugé trop complexe et abandonné :

http://blog.astrumfutura.com/archives/3 … nd_Di.html
http://www.ibuildings.com/blog/archives … llers.html

J'suis pas spécialiste du sujet. Mais visiblement, beaucoup s'accordent à dire que ça devrait être implémenté au niveau de PHP et non au niveau du framework étant donné que le framework offre déjà une couche d'abstraction normalement suffisante.

Pour ceux que l'injection de dépendances intéresse :
http://martinfowler.com/articles/injection.html

Extrêmement intéressant !

Quelques questions et/ou idées :
1/ En charge des objets. Le contrôleur manipule objet métier et service. Ok. Mais concrètement qui est en charge par exemple de la création d'un nouvel objet métier et qui est en charge de la récupération d'un objet existant ?
Dans le premier cas est-ce le contrôleur qui va faire un $myObject = new Model_Object() et le peuplé pour finalement le transmettre au service qui le sauvegardera ?
Et dans le second cas le contrôleur demandera au service de lui retourner un objet, via une instruction du type $myObject = $this->_testService->getObjectById(3) ?

2/ Activation des services via le helper. Si on se soucie peu de la performance, ne serait-il pas plus commode, à la place d'utiliser la méthode init() pour autoriser ou non les services, de définir un format spécifique pour la propriété qui réceptionne le service, et via le Helper de récupérer toutes les propriétés matchant ce format afin de leur fournir la classe de service attendue ? (dans l'idée au final de ne pas avoir à implémenter init() juste pour ça).

Au passage, property_exists() ne peut-il pas être remplacé par une réflexion qui vérifierait si la propriété existe bien et est publique ? (tout comme je pensais à la reflexion pour rapratrier toutes les propriétés attendant un service dans le contrôleur)

J'ai également lu tes participations au post "[ZF 1.7]Objets métiers et model" ( http://www.z-f.fr/forum/viewtopic.php?id=3679 ). De là en découlent du coup des questions annexes.

3/ Service et Mapper : Désormais ce n'est plus le mapper qui se charge de construire l'objet métier par rapport à la persistance, il se chargera seulement de faire des requêtes et d'en transmettre le résultat au Service qui lui construira l'objet métier ?

Si tel est le cas, qu'est ce que va transmettre précisément le mapper ? Un tableau associatif ?

Dernière modification par Eureka (19-08-2009 19:40:35)

Eureka a écrit:

1/ En charge des objets. Le contrôleur manipule objet métier et service. Ok. Mais concrètement qui est en charge par exemple de la création d'un nouvel objet métier et qui est en charge de la récupération d'un objet existant ?
Dans le premier cas est-ce le contrôleur qui va faire un $myObject = new Model_Object() et le peuplé pour finalement le transmettre au service qui le sauvegardera ?
Et dans le second cas le contrôleur demandera au service de lui retourner un objet, via une instruction du type $myObject = $this->_testService->getObjectById(3) ?

C'est tout à fait ça. Le controlleur connait l'objet métier, et connait les services qu'il peut consommer (petit détail, avec ma solution et du PHPDoc on a l'auto-completion sur les services). Le service lui, connait le metier, et il sait comment accéder à la persistance au travers des mappers, il va donc assurer la rencontre des deux.

En fait le service a plusieurs rôles. Il permet d'abord de découper et d'organiser correctement la logique de l'application. Il permet de cacher la complexité et l'organisation des modèles au controlleur, tout comme la façade, mais attention, contrairement à la façade les services assurent aussi du traitement, ils ne sont pas juste une interface, ils déterminent la logique applicative.

Un service doit donc fournir des méthodes qui répondent à la fois au métier et à la dynamique de l'application. Le controlleur lui n'a qu'un rôle de contrôle comme son nom l'indique. Il prend les informations de l'utilisateur, les vérifie, et les transmet à un service qui s'occupera du reste. Le controlleur sait ce qui doit être fait d'un objet, mais ne sait pas comment et n'a pas besoin de le savoir.

Le service agit donc dans les deux sens, il est capable de recevoir un objet métier et d'en faire quelque chose sur ordre du controlleur, et dans l'autre sens il doit être capable de retourner n'importe quel objet métier à la demande du controlleur.

Pour moi, et c'est une vision, il y en a d'autres. Les objets métiers sont les seuls entités que tout le monde connait, et ils sont la monnaie courante d'échange. Le controlleur ne devrait jamais rien manipuler d'autre concernant le modèle. Il a des données utilisateurs, il les valide et les filtres, il sait quel objet métier il doit peupler avec et sait sur quel bouton appuyer (méthode de service) pour déclencher la suite des opérations. Il reçoit une réponse, la formate et la rend à l'utilisateur.
Ou, l'utilisateur réclame une information, le controlleur sait à qui la demander (le service) et sous quelle forme il va la recevoir (objet métier) et renvoie tout ça à la vue (utilisateur). Son rôle s'arrête là en ce qui concerne le modèle.

Eureka a écrit:

2/ Activation des services via le helper. Si on se soucie peu de la performance, ne serait-il pas plus commode, à la place d'utiliser la méthode init() pour autoriser ou non les services, de définir un format spécifique pour la propriété qui réceptionne le service, et via le Helper de récupérer toutes les propriétés matchant ce format afin de leur fournir la classe de service attendue ? (dans l'idée au final de ne pas avoir à implémenter init() juste pour ça).

Alors, je change peu à peu d'avis. Je me rend compte que c'est très rare que les services ne soient pas utilisés dans les controlleurs. Je pense donc fournir plutôt une méthode disable() que enable() via le helper. Si on doit alors essayer de gagner la moindre milliseconde, il suffira de désactiver les services sur les controlleur qui ne les utilisent pas, ce qui évitera quelques boucles. Mais là il s'agit vraiment de micro-optimisation qui à mon avis ne rentre même pas en compte.

Pour ta solution, en ce qui concerne les performances, c'est kif kif, il faudra de toute façon parcourir les propriétés pour trouver celles qui match et les services pour y injecter le bon.
Comme je code avec un développeur Java, je voulais me rapprocher le plus possible du fonctionnent des bean, que je trouve d'ailleurs bien pratiques (xml).

Eureka a écrit:

Au passage, property_exists() ne peut-il pas être remplacé par une réflexion qui vérifierait si la propriété existe bien et est publique ? (tout comme je pensais à la reflexion pour rapratrier toutes les propriétés attendant un service dans le contrôleur)

Je ne veux justement pas que les propriétés soient publiques, elles doivent être protégées. La méthode property_exists me semble être la plus appropriée, PHP5.3 parlant bien sûr.

Eureka a écrit:

3/ Service et Mapper : Désormais ce n'est plus le mapper qui se charge de construire l'objet métier par rapport à la persistance, il se chargera seulement de faire des requêtes et d'en transmettre le résultat au Service qui lui construira l'objet métier ?

Si tel est le cas, qu'est ce que va transmettre précisément le mapper ? Un tableau associatif ?

Non, quand le controlleur réclame des données, il invoque le service, le service sait qui doit intervenir dans la persistance, il crée l'objet métier approprié, fait appel au mapper et le mapper peuple l'objet (passage par référence). L'objet est ensuite renvoyé au controlleur.

nORKy a écrit:

Des choses intéressantes à apprendre pt etre ici aussi : (et surement sur les liens qu'il donne)
http://www.whitewashing.de/blog/articles/117

J'avais lu cet article, il y a de l'idée, mais tout ceci ne permet pas d'injecter les services dans les controlleurs.
C'est ce point particulier que j'aborde ici, pas l'IOC au sens large. Ça viendra peut-être après, mais je suppose que Zend se penche déjà sur le problème, et qu'ils ne tarderont pas trop à proposer une solution.

A+ benjamin.

Salut,

La première idée pourrait effectivement faire l'objet d'une amélioration.

Par contre pour le reste, attention, l'injection de dépendances et aussi là (surtout ?) pour faciliter les tests unitaires. Le deuxième ne serait donc pas convenable, mais aussi hors conventions :p

Les conventions veulent qu'à une propriété corresponde un setter et/ou un getter. L'IOC ne fait qu'appeler le setter propre à la propriété à injecter.


A+ benjamin.