web-dev-qa-db-fra.com

Que sont les référentiels, les services et les actions / contrôleurs?

J'ai commencé un projet en utilisant Slim3 et PHP en utilisant une connaissance limitée de l'architecture de l'application. Le plan était de créer le projet et de séparer les problèmes d'application. Tout allait bien, mais les choses sont devenues rapidement confuses au fur et à mesure que l'application a grandi.

L'idée était de faciliter le développement. Il le fait d'une certaine manière, mais je trouve parfois difficile de garder un œil sur le flux de données.

J'ai besoin de conseils sur ce que sont les référentiels, les services et les contrôleurs/actions. Et comment ils devraient fonctionner dans un système. Ma compréhension actuelle d'eux est ci-dessous:

Référentiel

Les référentiels sont utilisés entre la couche service et la couche modèle. Par exemple, dans un UserRepository, vous créez des méthodes qui contiennent le code à lire/écrire à partir de la base de données. En PHP, PDO serait utilisé, ou un ORM, dans les méthodes de repo. Par exemple:

class UserRepository
{
    public function findByID($id) { ... }
    public function findByEmail($email) { ... }
    public function findByMobile($mobile) { ... }
    public function createEmail($email, $firstname, $lastname, $password) { ... }
    public function createMobile($mobile, $firstname, $lastname, $password) { ... }
}

J'ai mis quelques exemples de méthodes là-dedans. Mais il y en aurait probablement beaucoup plus.

Services

La couche de service encapsule la logique d'application. Par exemple, le UserService serait responsable de la création d'un compte et de l'exécution de la logique requise pour enregistrer l'utilisateur. Les services peuvent également être tiers, par exemple en créant un service pour le SDK de Facebook ou ORM.

Un exemple de service:

class UserService
{
    public function createMobile($mobile, $firstname, $lastname, $password)     {
    /*
     * Call a validation service to validate input
     */
    ...

    /*
     * Use UserRepository's findByMobile() to check if account exists
     */
    ...

    /*
     * Use UserRepository's createMobile() to create account
     */
    ...

    /*
     * Call SMS service to send verification code
     */
    ...
    }

    public function createEmail(...) { ... }
    public function getFollowers (...) { ... }
}

Actions

Je ne sais pas si c'est un vrai terme. Il est utilisé dans la documentation Slim Framework et semble représenter un contrôleur mince.

Une action contient très peu de logique et est utilisée pour effectuer des appels aux services. L'action effectue rarement des appels directs aux référentiels, sauf s'il existe une raison valable. L'action effectuera des contrôles de base sur les données renvoyées par les services afin de renvoyer une réponse au client.

Ils sont liés à des itinéraires individuels. Je les utilise comme ça:

class ActivateEmailAction extends Action {

    public function __invoke(Request $request, Response $response, $args = [])
    {
        if(!$this->ci->ActivationService->activateEmail($args['token'])){
            return $response->withJson([
                'status' => 'error',
                'data' => null,
                'message' => 'Invalid verification token'
            ]);
        };

        return $response->withJson([
            'status' => 'success',
            'data' => null,
            'message' => null
        ]);
    }
}

Suis-je en utilisant ces modèles correctement? Le flux que je semble avoir adopté est le suivant:

  1. Tout commence par l'itinéraire. Par exemple, une demande est adressée à /create. L'itinéraire est enregistré dans une action.
  2. L'action décide des services à appeler
  3. Les services exécutent la logique, appellent d'autres services et référentiels si nécessaire
  4. Le service remet les données à l'action
  5. L'action renvoie une réponse

Tout conseil serait très apprécié.

design-patternsobject-oriented-design
7
BugHunterUK

J'aime vraiment la façon dont vous mettez cela en œuvre.

Quelques réponses:

Que sont les référentiels, les services et les actions/contrôleurs?

  • Référentiels: Le référentiel est une passerelle entre votre couche domaine/entreprise et une couche de mappage de données, qui est la couche qui accède à la base de données et effectue les opérations. Fondamentalement, le référentiel est une abstraction pour votre accès à la base de données.

  • Service: Le service devrait fournir une API à votre logique métier, étant donc une abstraction pour votre référentiel, voici où je suis en désaccord, juste un peu, avec @Cerad, les services devraient être les seuls avec l'accès aux référentiels, sinon il viole le principe d'inversion des dépendances (D dans SOLID), car la couche métier est une abstraction de votre couche d'accès aux données.

  • Actions/Contrôleurs: Les objets A/C fonctionnent comme une passerelle entre votre entrée et la logique du domaine, décide quoi faire de l'entrée et comment sortir la réponse.

Je trouve parfois difficile de garder un œil sur le flux de données.

Oui, parfois c'est le cas, mais comme je l'ai lu, et je ne m'en souviens pas bien, il vaut mieux avoir un code organisé et basé sur des principes que d'avoir de dernières difficultés sur du code laid, cela le rend plus gérable, lisible et maintenable.

Finalement:

Le modèle architectural que vous utilisez est l'architecture en couches, tout est séparé en couches et les couches supérieures sont des abstractions des couches inférieures, c'est pourquoi chaque couche ne doit référencer que la couche inférieure immédiate.

J'espère que cela t'aides.

9
J. Pichardo