Discussion :

[Nathanael Marchand]

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

[Z3vil]

5/5

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

rien a dire.

[Louis-Guillaume Morand]

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

[Er3van]

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 [...]"

[camus3]

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

[Nathanael Marchand]

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

[Immobilis]

Salut,

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

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[Nathanael Marchand]

Salut,

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

Merci

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

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)

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

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

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

[Immobilis]

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

Ben justement, l'utilisation d'interface a surtout cet intérêt d'apporter la généricitude , 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

[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).

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

et l'appeler avec un

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[rad_hass]

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 ?

[Nathanael Marchand]

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

[rad_hass]

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"

[Nathanael Marchand]

Oui mais j'ai encore jamais vu de couche Business générique
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.

[Immobilis]

CRUD suffit mais sur du business

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