L'inversion de dépendances bien appliquée donne flexibilité et stabilité au niveau de toute l'architecture de votre application. Cela permettra à votre application d'évoluer de manière plus sécurisée et stable.
Architecture traditionnelle en couches
Traditionnellement, une interface utilisateur à architecture en couches dépendait de la couche métier et cela dépendait à son tour de la couche d'accès aux données.
Vous devez comprendre la couche, le package ou la bibliothèque. Voyons comment serait le code.
Nous aurions une bibliothèque ou un package pour la couche d'accès aux données.
// DataAccessLayer.dll
public class ProductDAO {
}
Et une autre logique métier de couche de bibliothèque ou de package qui dépend de la couche d'accès aux données.
// BusinessLogicLayer.dll
using DataAccessLayer;
public class ProductBO {
private ProductDAO productDAO;
}
Architecture en couches avec inversion des dépendances
L'inversion de dépendance indique ce qui suit:
Les modules de haut niveau ne doivent pas dépendre de modules de bas niveau. Les deux devraient dépendre d'abstractions.
Les abstractions ne doivent pas dépendre des détails. Les détails doivent dépendre des abstractions.
Quels sont les modules de haut niveau et de bas niveau? En pensant aux modules tels que les bibliothèques ou les packages, les modules de haut niveau seraient ceux qui ont traditionnellement des dépendances et de bas niveau dont ils dépendent.
En d'autres termes, le niveau haut du module serait l'endroit où l'action est invoquée et le niveau bas où l'action est exécutée.
Une conclusion raisonnable à tirer de ce principe est qu'il ne doit pas y avoir de dépendance entre les concrétions, mais qu'il doit y avoir une dépendance à une abstraction. Mais selon l'approche que nous adoptons, nous pouvons mal appliquer la dépendance à l'investissement, mais une abstraction.
Imaginez que nous adaptons notre code comme suit:
Nous aurions une bibliothèque ou un package pour la couche d'accès aux données qui définissent l'abstraction.
// DataAccessLayer.dll
public interface IProductDAO
public class ProductDAO : IProductDAO{
}
Et une autre logique métier de couche de bibliothèque ou de package qui dépend de la couche d'accès aux données.
// BusinessLogicLayer.dll
using DataAccessLayer;
public class ProductBO {
private IProductDAO productDAO;
}
Bien que nous dépendions d'une abstraction, la dépendance entre les entreprises et l'accès aux données reste la même.
Pour obtenir une inversion de dépendance, l'interface de persistance doit être définie dans le module ou le package où se trouve cette logique ou ce domaine de haut niveau et non dans le module de bas niveau.
Définissez d'abord ce qu'est la couche de domaine et l'abstraction de sa communication est définie comme la persistance.
// Domain.dll
public interface IProductRepository;
using DataAccessLayer;
public class ProductBO {
private IProductRepository productRepository;
}
Une fois que la couche de persistance dépend du domaine, il faut s'inverser maintenant si une dépendance est définie.
// Persistence.dll
public class ProductDAO : IProductRepository{
}
(source: xurxodev.com )
Approfondir le principe
Il est important de bien assimiler le concept, d'approfondir le but et les avantages. Si nous restons mécaniquement et apprenons le référentiel de cas typique, nous ne serons pas en mesure d'identifier où nous pouvons appliquer le principe de dépendance.
Mais pourquoi inversons-nous une dépendance? Quel est l'objectif principal au-delà des exemples spécifiques?
Cela permet généralement aux choses les plus stables, qui ne dépendent pas de choses moins stables, de changer plus fréquemment.
Il est plus facile pour le type de persistance d'être changé, que ce soit la base de données ou la technologie pour accéder à la même base de données que la logique de domaine ou les actions conçues pour communiquer avec persistance. Pour cette raison, la dépendance est inversée car il est plus facile de modifier la persistance si ce changement se produit. De cette façon, nous n'aurons pas à changer de domaine. La couche de domaine est la plus stable de toutes, c'est pourquoi elle ne devrait dépendre de rien.
Mais il n'y a pas que cet exemple de référentiel. Il existe de nombreux scénarios où ce principe s'applique et il existe des architectures basées sur ce principe.
Architectures
Il existe des architectures où l'inversion des dépendances est la clé de sa définition. Dans tous les domaines, c'est le plus important et ce sont les abstractions qui indiqueront que le protocole de communication entre le domaine et le reste des packages ou bibliothèques sont définis.
Architecture propre
Dans l' architecture propre, le domaine est situé au centre et si vous regardez dans le sens des flèches indiquant la dépendance, il est clair quelles sont les couches les plus importantes et les plus stables. Les couches extérieures sont considérées comme des outils instables, alors évitez de dépendre d'eux.
(source: 8thlight.com )
Architecture hexagonale
Il en va de même avec l'architecture hexagonale, où le domaine est également situé dans la partie centrale et les ports sont des abstractions de communication depuis le domino vers l'extérieur. Là encore, il est évident que le domaine est le plus stable et la dépendance traditionnelle est inversée.
