[Article] Architecture en couches, découplage et injection de dépendances avec Unity

Avec des architectures informatiques toujours plus complexes, des méthodes de développement exigeant toujours plus de flexibilité, l'injection de dépendances, le découplage et l'architecture en couches sont de bons moyens de répondre à ces problématiques et ainsi s'assurer d'avoir un système d'information cohérent, flexible et robuste.
Dans cet article nous allons étudier Unity, le framework d'injection de dépendances de Microsoft afin de mettre en place une architecture en couches découplées.

J'ouvre cette discussion pour recueillir vos commentaires, questions et remarques sur l'article : Architecture en couches, découplage et injection de dépendances avec Unity

Pour la lecture c'est par ici:
http://nathanaelmarchand.developpez....es-avec-unity/

Bonne lecture :)

:ccool: 5/5

Citation:

---

... ainsi d'utiliser Spring.Net par exemple à la place de Unity.

---

rien a dire.

ca fait bien un an que j'ai pas lu un article DVP, tu vas être le premier :)

Très bon article, simple et complet, rien à redire !


Les quelques coquilles que j'ai noté :

IV-A. Le pattern ServiceLocator : "[...] permet éventuellement l'utilisation d'autres gestionnaires d'injection

IV-C. Les injections non triviales : "Jusqu'à présent, nous avons utilisé des cas de figures assez simples [...] quand même un constructeur sans paramètre [...]

VI-A. L'interception : "La notion d'interception est un peu? plus complexe [...]"

Conclusion : "Dans les prochains articles [...]"

Très bon article, sur ce sujet un peu effrayant qu'est l'injection de dépendance entre autres :)

Merci pour vos retours! :)
2700pages vues et 1000visiteurs depuis 10h ce matin, je suis impressioné :D
Er3van: Merci! Je corrigerai les fautes demain Corrigé!

Salut,

Article intéressant effectivement, très bien écrit :ccool: même si manque un peu d'illustrations :aie:

Sur le concept en lui-même, comment fais-tu pour valider la configuration? Je suis assez confiant quand je compile les solutions de VS car les références à mes objets/interface sont explicites. J'imagine que quand on utilise Unity cette opération se fait à l’exécution. N'est-ce pas pénalisant?

Cette méthode de développement est certainement efficace mais à mon avis, l'indépendance qu'elle procure est un peu une illusion. A un moment donné, il faut quand même faire le mapping. VS supporte-t-il l'intellisense dans le fichier de config?

Dans ton architecture tu as créé une classe BusinessLogic. Est-elle dédiée à tous les objets? Pourrait-elle être renommée MovieLogic et l'interface IMovieLogic? Du coup, DataAccess pourrait aussi être renommée MovieDataAccess et IMovieDataAccess.

Cependant, on perd un peu en généricité. A moins de renommer les méthodes de la logique métier, comment réécrire le code ci-dessous pour profiter des fonctionnalité de Unity et préserver la généricité:

Code:

---

1 2 3 4 5 6 7 8 9

if (!Page.IsPostBack) { var businessLayer = ServiceLocator.Current.GetInstance<IMovieLogic>();   var movies = businessLayer.GetMovies();   grdMovies.DataSource = movies; grdMovies.DataBind(); }

---

A+

Encore beau travail :ccool:

Citation:

---

Envoyé par Immobilis

Salut,

Article intéressant effectivement, très bien écrit :ccool: même si manque un peu d'illustrations :aie:

---

Merci :ccool:

Citation:

---

Envoyé par Immobilis

Sur le concept en lui-même, comment fais-tu pour valider la configuration? Je suis assez confiant quand je compile les solutions de VS car les références à mes objets/interface sont explicites. J'imagine que quand on utilise Unity cette opération se fait à l’exécution. N'est-ce pas pénalisant?

---

Effectivement, ca se fait à l'execution, mais tu te fais assez vite engueuler quand il y a quelque chose qui ne va pas :aie:

Citation:

---

Envoyé par Immobilis

Cette méthode de développement est certainement efficace mais à mon avis, l'indépendance qu'elle procure est un peu une illusion. A un moment donné, il faut quand même faire le mapping. VS supporte-t-il l'intellisense dans le fichier de config?

---

L'intellisense marche pour la structure du fichier de config (quelle balise va ou par exemple) mais pas pour le nom des classes (mais c'est peu gênant: voir réponse du dessus)

Citation:

---

Envoyé par Immobilis

Dans ton architecture tu as créé une classe BusinessLogic. Est-elle dédiée à tous les objets? Pourrait-elle être renommée MovieLogic et l'interface IMovieLogic? Du coup, DataAccess pourrait aussi être renommée MovieDataAccess et IMovieDataAccess.

---

Ben la j'avais qu'une entité et qu'une zone métier donc effectivement le découpage assez simple. D'apres moi un objet BusinessLogic interagit avec plusieurs objets DataAccess selon des périmètres fonctionnels. Cela dit, tu peux découper comme ca te chante :D

Citation:

---

Envoyé par Immobilis

Cependant, on perd un peu en généricité. A moins de renommer les méthodes de la logique métier, comment réécrire le code ci-dessous pour profiter des fonctionnalité de Unity et préserver la généricité:

Code:

---

1 2 3 4 5 6 7 8 9

if (!Page.IsPostBack) { var businessLayer = ServiceLocator.Current.GetInstance<IMovieLogic>();   var movies = businessLayer.GetMovies();   grdMovies.DataSource = movies; grdMovies.DataBind(); }

---

A+

Encore beau travail :ccool:

---

Comment voudrais tu génériciser (si le mot existe :aie:)? A un moment faut bien spécialiser non? :mrgreen:

Citation:

---

Envoyé par Nathanael Marchand

Comment voudrais tu génériciser (si le mot existe :aie:)? A un moment faut bien spécialiser non? :mrgreen:

---

Ben justement, l'utilisation d'interface a surtout cet intérêt d'apporter la généricitude :mouarf:, sinon, je ne vois pas trop l'intérêt et autant utiliser la classe. Non?
Est-ce que le ServiceLocator est une sorte de fabrique?

Un peu de généricitude ici: http://immobilis.developpez.com/tuto...work/#LIII-A-2

Ah ok je vois. Bon, autant génériciser la couche DataAccess, why not, autant la couche business je pense que bien que cela soit faisable techniquement, fonctionnellement je doute de l'interet (en pratique t'auras jamais du business commun).

Tu peux référencer ton ICrud<T> comme ceci:

Code:

---

<register type="ICrud[MyEntity]" />

---

et l'appeler avec un

Code:

---

ServiceLocator.Current.GetInstance<ICrud<Movie>>();

---

Citation:

---

Envoyé par Nathanael Marchand

Ah ok je vois. Bon, autant génériciser la couche DataAccess, why not, autant la couche business je pense que bien que cela soit faisable techniquement, fonctionnellement je doute de l'interet (en pratique t'auras jamais du business commun).

---

Quid du mock et autre test unitaire ?

Citation:

---

Envoyé par rad_hass

Quid du mock et autre test unitaire ?

---

Euh ben ca marche! L'interface ICrud<MonEntite> résoud sur Crud<MonEntite> ou sur CrudMock<MonEntite> selon la config :)

Citation:

---

Envoyé par Nathanael Marchand

Euh ben ca marche! L'interface ICrud<MonEntite> résoud sur Crud<MonEntite> ou sur CrudMock<MonEntite> selon la config :)

---

Non je parlais de la couche business... C'est une réaction à ton propos "fonctionnellement je doute de l'interet"

Oui mais j'ai encore jamais vu de couche Business générique 8O
Autant des couches d'acces aux données ca peut être générique si le CRUD suffit mais sur du business...

Si je prends un truc de facturation par exemple: j'ai un OrderManager et un CustomerManager. Alors je peux faire un Crud<T> où T est Order ou Customer. Mais je doute que la logique soit si commune dans les manager au point de faire un Manager<T>.

Et avoir un OrderManager + CustomerManager ne t'empeche pas de faire des tests unitaires, il te faut juste une interface IOrderManager avec OrderManager et OrderManagerMock, pareil pour CustomerManager.

Citation:

---

Envoyé par Nathanael Marchand

CRUD suffit mais sur du business

---

Le CRUD sur le business c'est déjà un bon morceau.