IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

MVC Discussion :

MVC et dépendances de classes


Sujet :

MVC

  1. #1
    Membre régulier
    Inscrit en
    Novembre 2007
    Messages
    176
    Détails du profil
    Informations forums :
    Inscription : Novembre 2007
    Messages : 176
    Points : 94
    Points
    94
    Par défaut MVC et dépendances de classes
    Salut,

    J'ai développé une application en me basant sur le modèle MVC en PHP (sans aucun framework). Toutes mes classes modèles créent une classe qui standardise la manière de faire des requêtes en utilisant pdo et une autre classe qui passe les requêtes sql. Voila un constructeur type d'une classe modèle dans mon code:

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    	public function __construct()
    	{
    		$this->conn = new PdoQueries();
    		$this->db = new UserDb($this->conn);
    	}
    En ce moment je suis entrain d'écrire les tests unitaires et j'ai remarqué que d'une part, c'est plus facile d'utiliser des mocks si au lieu d'instantier ces dépendances dans le constructeur, je les passe comme paramètres au constructeurs. D'aute part si elles sont passées en paramètre au constructeur, quand j'instantie une classe modèle dans le controleur je dois d'abord instantier ses dépendances, ce qui rend les contrôleurs plus couplés avec les modèles.

    C'est quoi la meilleur option à votre avis?

    Merci

  2. #2
    Membre émérite
    Inscrit en
    Janvier 2011
    Messages
    805
    Détails du profil
    Informations personnelles :
    Localisation : Autre

    Informations forums :
    Inscription : Janvier 2011
    Messages : 805
    Points : 2 917
    Points
    2 917
    Par défaut
    Hello,

    C'est plutôt une bonne pratique de passer les dépendances dans le constructeur Comme tu l'as justement noté, cela rend le code plus testable, et aussi plus maintenable car s'il y a besoin de changer l'implémentation concrète d'une dépendance, ce n'est plus dans la classe qui en dépend qu'on va modifier quelque chose mais à l'extérieur. Cela la rend moins fragile et plus robuste aux changements.

    Mais tout n'est pas si simple, car il y a deux types de dépendances : celles dont on veut qu'elles soient présentes tout au long de la vie de l'objet, et celles dont on n'a besoin que ponctuellement. Dans ton code, on n'a par exemple pas forcément envie de garder une connexion base de données ouverte tout le temps et donc pas envie que les objets "du dessus" se la trimballent à vie pour qu'au final elle soit utilisée très épisodiquement dans un objet "du dessous".

    Dans ce cas, on peut donc utiliser une dépendance capable de créer des dépendances, à savoir une Factory. La Factory elle-même peut être injectée dans le constructeur et traitée comme une dépendance "à vie", mais on pourra l'appeler quand on veut pour qu'elle fabrique des rejetons à durée de vie taillée sur mesure. Attention toutefois à ne pas abuser des Factory qui restent adaptées à un usage très particulier - la plupart du temps, passer une dépendance normale suffit, surtout dans les contextes applicatifs ou le process ne dure que quelques instants comme une application web.

    Dans ton cas, on pourrait donc avoir la chaîne de dépendances
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    new Controller(new Model(new ConnectionFactory(...)))
    A noter que dans cet assemblage, ce n'est pas le Controller qui connait la classe ConnectionFactory concrète à instancier, le controller n'a pas de dépendance directe sur cette classe. C'est le contexte global, un niveau au-dessus, qui instancie le Controller et tous les objets de la chaîne. C'est ce qu'on appelle une Composition Root : un endroit unique situé à l'entrée de l'application et qui va composer toute notre grappe de dépendances. J'imagine qu'on doit pouvoir faire ça en PHP en se branchant sur l'arrivée d'une requête HTTP. Sinon, des frameworks d'injection de dépendance (IoC Container) doivent permettre de le faire. Ces frameworks offrent des facilités supplémentaires pour gérer la résolution l'assemblage des dépendances entre elles.

  3. #3
    Expert éminent sénior
    Homme Profil pro
    Analyste/ Programmeur
    Inscrit en
    Juillet 2013
    Messages
    4 627
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Analyste/ Programmeur

    Informations forums :
    Inscription : Juillet 2013
    Messages : 4 627
    Points : 10 548
    Points
    10 548
    Par défaut
    Dependency injection pour le terme technique

  4. #4
    Membre régulier
    Inscrit en
    Novembre 2007
    Messages
    176
    Détails du profil
    Informations forums :
    Inscription : Novembre 2007
    Messages : 176
    Points : 94
    Points
    94
    Par défaut
    Salut,

    Merci beaucoup pour ton excellente réponse.

    Bonne journée

    Citation Envoyé par Luckyluke34 Voir le message
    Hello,

    C'est plutôt une bonne pratique de passer les dépendances dans le constructeur Comme tu l'as justement noté, cela rend le code plus testable, et aussi plus maintenable car s'il y a besoin de changer l'implémentation concrète d'une dépendance, ce n'est plus dans la classe qui en dépend qu'on va modifier quelque chose mais à l'extérieur. Cela la rend moins fragile et plus robuste aux changements.

    Mais tout n'est pas si simple, car il y a deux types de dépendances : celles dont on veut qu'elles soient présentes tout au long de la vie de l'objet, et celles dont on n'a besoin que ponctuellement. Dans ton code, on n'a par exemple pas forcément envie de garder une connexion base de données ouverte tout le temps et donc pas envie que les objets "du dessus" se la trimballent à vie pour qu'au final elle soit utilisée très épisodiquement dans un objet "du dessous".

    Dans ce cas, on peut donc utiliser une dépendance capable de créer des dépendances, à savoir une Factory. La Factory elle-même peut être injectée dans le constructeur et traitée comme une dépendance "à vie", mais on pourra l'appeler quand on veut pour qu'elle fabrique des rejetons à durée de vie taillée sur mesure. Attention toutefois à ne pas abuser des Factory qui restent adaptées à un usage très particulier - la plupart du temps, passer une dépendance normale suffit, surtout dans les contextes applicatifs ou le process ne dure que quelques instants comme une application web.

    Dans ton cas, on pourrait donc avoir la chaîne de dépendances
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    new Controller(new Model(new ConnectionFactory(...)))
    A noter que dans cet assemblage, ce n'est pas le Controller qui connait la classe ConnectionFactory concrète à instancier, le controller n'a pas de dépendance directe sur cette classe. C'est le contexte global, un niveau au-dessus, qui instancie le Controller et tous les objets de la chaîne. C'est ce qu'on appelle une Composition Root : un endroit unique situé à l'entrée de l'application et qui va composer toute notre grappe de dépendances. J'imagine qu'on doit pouvoir faire ça en PHP en se branchant sur l'arrivée d'une requête HTTP. Sinon, des frameworks d'injection de dépendance (IoC Container) doivent permettre de le faire. Ces frameworks offrent des facilités supplémentaires pour gérer la résolution l'assemblage des dépendances entre elles.

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. MVC et dépendance circulaire de projets
    Par AsPrO dans le forum MVC
    Réponses: 7
    Dernier message: 14/11/2011, 17h04
  2. Dépendance de class
    Par coach759 dans le forum Langage
    Réponses: 1
    Dernier message: 27/10/2010, 18h57
  3. Réponses: 0
    Dernier message: 06/05/2010, 19h34
  4. Réponses: 27
    Dernier message: 30/10/2007, 11h12
  5. Réponses: 2
    Dernier message: 14/09/2007, 09h55

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo