Discussion :

[M_Makia]

Bonjour � toutes et � tous,

Ma question se porte sur l'architecture a adopter avec une application web 3-Tiers avec de l'injection de d�pendance.
Dans la plus part des tutos et des projets que j'ai pu croiser on retrouve les interfaces et les impl�mentations dans le m�me assembly et je trouve �a �trange.

Par exemple, dans la couche d�acc�s au donn�es on peut trouver ICustomerRepository et son impl�mentation CustomerRepository.
Si je pars du principe que ICustomerRepository sera r�f�renc� dans les autres couches il faudra forcement mettre en tant que r�f�rence l'assembly contenant les interfaces et les impl�mentations.

Donc si demain je souhaite changer ma couche d�acc�s au donn�es via le moteur d'injection de d�pendance je suis oblig� de garder en r�f�rence ma premi�re assembly car elle contient les interfaces indispensables et les impl�mentations qui ne sont plus utilis�es.

Ne faut-il pas mettre toutes les interfaces dans une "couche" distincte afin de ne pas m�langer interfaces et impl�mentations dans une m�me couche ?

Merci pour vos retours.

[MoscoBlade]

Bonjour,

Voici l'architecture que j'aime bien appliquer, il s'agit d'une architecture "onion" (http://jeffreypalermo.com/blog/the-o...ecture-part-1/).

Appli web :
- Controller
- Model � afficher
- Vues

Domain :
- classe m�tier
- Interface m�tier (repo ou autres)
- Service m�tier (m�thodes m�tier)

Infrastructure :
- impl�mentation d'interface
- acc�s � la db
- log
- autres ...

Tests :
- Tests unitaires
- Tests d'acceptances

Un peu dans ce genre l� http://www.c-sharpcorner.com/UploadF...n-Asp-Net-mvc/

Mosco

[MoscoBlade]

Ma r�ponse pr�c�dente est hors-sujet ! J'ai lu un peu beaucoup trop vite.

[M_Makia]

Merci pour ta r�ponse m�me si elle est effectivement hors sujet ^^
Est-ce que tu as tout de m�me un avis sur la question ?

[MoscoBlade]

J'imagine que ton architecture est repr�sent� de la mani�re suivante ?

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
 
Web : Presentation Layer (ASP.NET MVC par exemple) (connait seulement BLL)
BLL : Business Logic Layer (connait DAL)
DAL : Data Access Layer

J'ai regard� les liens suivants pour voir (je n'utilise plus cette architecture)
https://www.developer.com/net/depend...plication.html
https://github.com/manoj-kumar1/DI-B...yDemo-Solution
http://www.fonteyne.net/post/Injecti...ependance.aspx

C'est vrai que les liens entre les diff�rentes assemblies ne permettent pas de d�clarer les interfaces comme je l'aurais voulu.
Depuis quelques temps j'ai pris l'habitude d'utiliser de travailler avec l'architecture onion qui place le m�tier au coeur de l'application.

D�sol� encore d'avoir r�pondu dans le vent !!!
Je suis int�ress� par un �ventuel retour sur les bonnes pratiques, car de ce que j'ai vu cela ne me semble pas si logique que �a.


Mosco.

[DotNetMatt]

Ma question se porte sur l'architecture a adopter avec une application web 3-Tiers avec de l'injection de d�pendance.

L'injection de dependances ne change quasiment rien a l'architecture en tant que tel. Le principe de base c'est que tu puisses simplement remplacer une DLL v2.1 par une DLL v2.2 par exemple, sans avoir a tout redeployer. Donc on decouple le code un maximum et on garanti le fonctionnement via des contrats que sont les interfaces. Cela permet egalement de faciliter les tests unitaires, puisqu'on teste contre l'interface et non contre l'implementation qui peut changer a tout instant.

Dans la plus part des tutos et des projets que j'ai pu croiser on retrouve les interfaces et les impl�mentations dans le m�me assembly et je trouve �a �trange.

Cela peut avoir du sens selon pourquoi est-ce que tu utilises l'injection de dependences. Si ton objectif est simplement de pouvoir tester ton code plus facilement, et/ou si tu es en TDD, alors ca fait sens.

Par exemple, dans la couche d�acc�s au donn�es on peut trouver ICustomerRepository et son impl�mentation CustomerRepository.
Si je pars du principe que ICustomerRepository sera r�f�renc� dans les autres couches il faudra forcement mettre en tant que r�f�rence l'assembly contenant les interfaces et les impl�mentations.
[...]
Ne faut-il pas mettre toutes les interfaces dans une "couche" distincte afin de ne pas m�langer interfaces et impl�mentations dans une m�me couche ?

Tout a fait, tu peux avoir une structure de projets comme ceci par exemple :

- Projet.DataTransferObjects
- Projet.DataAccessLayer.Interfaces (ICustomerRepository)
- Projet.DataAccessLayer (CustomerRepository)
- Projet.BusinessLayer.Interfaces
- Projet.BusinessLayer
- Projet.Web

Ainsi, si CustomerRepository vient a changer, il te suffira de remplacer l'assembly Projet.DataAccessLayer.

Tu peux meme decouper encore plus, si necessaire :

- Projet.DataTransferObjects
- Projet.DataAccessLayer.Sales.Interfaces (ICustomerRepository)
- Projet.DataAccessLayer.Sales (CustomerRepository)
- Projet.DataAccessLayer.Marketing.Interfaces
- Projet.DataAccessLayer.Marketing
- Projet.DataAccessLayer.Finance.Interfaces
- Projet.DataAccessLayer.Finance
- Projet.BusinessLayer.Interfaces
- Projet.BusinessLayer
- Projet.Web

Tout depend des besoins du projet, de la flexibilite dont tu as besoin pour tes deploiements, pour tes tests, etc.

[MoscoBlade]

merci pour l'explication

Mosco

[M_Makia]

Merci pour ta r�ponse !