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 !