Accueil > Pattern > Inversion de contrôle et injection de dépendance, ça se mange ?

Inversion de contrôle et injection de dépendance, ça se mange ?

Inversion de contrôle (IoC) et injection de dépendance (DI), ça se mange ?

Et bien non 😀

Ce post ne prétend pas être un vrai cours sur l’Inversion de contrôle (ou IoC). Pour y aller plus loin, je vous conseille de visiter le site de Windsor Castle ( http://www.castleproject.org/), ou celui de Unity (http://unity.codeplex.com/), ou d’autres pour les autres technos OO comme Java…

Néanmoins, pour ceux qui débutent, ce post peut servir, du moins pour avoir en tête ce que IoC et DI veulent dire. A priori, ces deux termes signifient pratiquement la même chose, mais à mon avis; parler de IoC ou de DI, dépend de l’angle prise pour observer le système mis en place.

IoC, pourquoi ?

Dans la plupart des architectures logicielles, au début de la tendance vers la conception orientée-objets; les différentes couches se dépendent de façon hiérarchique. Par exemple, dans une application simple et classique de gestion qui interagit avec une base de données, on a généralement le type de dépendance suivant : la couche présentation dépend de la couche métier, et puis la couche métier dépend de la couche d’accès aux données, … Ceci peut être schématisé comme suit (remarquez les sens des flèches : couche x => couche y (couche  x dépend de y)

Architecture_simple

 

 

Un peu plus tard, les architectes et développeurs se sont rendus très vite que si la couche métier dépend de la couche d’accès aux données, on est sujet à trois problèmes (et peut-être d’autres) :

1. le métier ne peut pas évoluer tout seul, car il dépend de la couche d’accès aux données. Autrement dit, la couche de données connaît toutes les évolutions du métier, ce qui n’est pas souhaitable car dans ce cas, pourquoi on les sépare en deux couches distinctes ?

2. le métier n’est pas testable « unitairement », car pour pouvoir l’exécuter, il faut que la couche de données existe et tourne avec lui.

3. si on veut changer de couche d’accès aux données, la couche métier doit s’adapter à la nouvelle couche. Alors que comme son nom l’indique, c’est une couche « Métier », c’est elle qui doit diriger tout dans l’architecture…

Il faut alors inverser la dépendance entre ces deux couches, et faire en sorte que le métier soit le centre. Autant que possible, il faut que les autres couches dépendent du métier, et non l’inverse. C’est à partir de cette idée comme quoi l’architecture soit focalisée au métier, qu’est venu – à mon avis – le terme : Domain Driven Design (conception orientée domaine (sous-entendu métier)) => c’est lé métier qui dirige tout, et tout (ou presque tout) doit dépendre du métier. Lorsqu’ on inverse la dépendance entre les couches pour que le métier soit le centre, on fait techniquement une « Inversion de contrôle » (IoC). Dans le schéma ci-dessus, imaginez juste que la flèche qui monte du métier vers la couche de données se dirige dans le sens inverse.

Comment on fait pratiquement ? La réponse sera sujet à un autre poste (pour que nous nous embrouillions pas dans du code mais juste dans l’explication)…

 

Si Inversion de contrôle, alors Injection de dépendance !

Maintenant, comme la couche métier est le centre de l’architecture, la couche présentation ainsi que la couche de données, et d’autres (…) dépendent donc du métier. Mais lorsqu’on écrira nos premiers codes de CRUD (ou pour commencer juste une requête) : on constatera rapidement que la couche présentation ne pourra pas s’exécuter car il ne dépend que de la couche « métier » (ce qui est bien 🙂 ), et comme cette couche métier ne dépend plus de la couche d’accès aux données; cette couche de données n’est plus accessible à la présentation (même d’une façon indirecte). Ce qui veut dire simplement que la couche présentation ne peut plus manipuler les données, même à travers la couche métier. Ce qui est insensé dans une application de gestion !

Il faut alors permettre à la couche présentation d’avoir une visibilité des couches environnantes au métier pour qu’au final, cette couche (la plus basse) puisse exploiter « indirectement » les autres couches, entre autres celle qui accède aux données. Autrement dit, il faut « injecter » à la couche d’utilisation (ici la présentation) les dépendances aux autres couches qui dépendent du métier, d’où le terme « Injection de dépendance« . C’est pourquoi je disais plus haut : l’appellation IoC ou DI dépend de l’angle d’où on regarde l’architecture… Dans la pratique, afin de pouvoir réaliser cette injection de dépendance, on fait appel à des outils tiers comme Windsor Castle ou Microsoft Unity dans le cas des technologies .Net.

architecture_IoC

 

Et pour les vrais débutants en POO, ne vous aventurez pas dans les IoC ni les DI, qu’après avoir maîtrisé l’utilisation (et donc l’utilité ou l’inutilité) des interfaces.

Publicités
Catégories :Pattern
  1. Kakanjila
    mars 14, 2013 à 07:40

    Illustre avec un code très simple si possible!!

    • mars 14, 2013 à 09:51

      Kakanjila > dans le prochain poste 😉

  1. avril 13, 2013 à 17:10
  2. mai 28, 2013 à 21:26

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s

%d blogueurs aiment cette page :