Dépendances circulaires
J'ai 2 projets.
Le projet n ° 2 fait référence au projet n ° 1
Maintenant, je dois référencer le projet n ° 2 dans le projet n ° 1, mais vs.net se plaint d'une dépendance circulaire.
Y a-t-il un moyen de s'en sortir?
Absolument pas. Les dépendances circulaires indiquent une mauvaise conception. Je ne veux pas être sévère. Il y a des moyens de s'en sortir.
1) Vous pouvez refactoriser le code commun vers un autre projet, par exemple Project # 0
2) Vous pouvez corriger votre conception, ce qui est probablement la voie à suivre.
Oncle Bob a un bon article sur les principes d'emballage qui comprend le principe des dépendances acycliques. http://www.objectmentor.com/resources/articles/granularity.pdf . Lisez ceci pour savoir pourquoi les dépendances cycliques sont une mauvaise chose.
Refactorisez vos projets pour extraire les éléments communs dans un "Projet # 0" auquel font référence à la fois le Projet # 1 et le Projet # 2.
Fusionnez les deux en un ou remodelez.
Cela indique un problème dans votre conception. S'il existe un réel besoin que deux ou plusieurs de vos types soient mutuellement conscients, ils doivent exister dans la même assemblée.
Non. Structurez correctement vos projets. Essayez d'utiliser une sorte de classement basé sur l'abstraction - de bas niveau à haut niveau.
Une dépendance circulaire signifie qu'il ne s'agit plus de deux projets indépendants (car il est impossible d'en construire un seul).
Vous devez soit refactoriser pour ne disposer que d'une dépendance à sens unique, soit les fusionner en un seul projet.
La référence circulaire peut se faire comme on le voit dans un question précédente , mais vous ne devriez pas faites-le pour les raisons que tout le monde a déjà mentionnées ici.
Je vraiment ne signifie pas être un smart-aleck, mais une meilleure conception de programme est la réponse.
Cela semble être un défaut de conception, rien d'autre. La re-conception est la solution.
Tout le monde vous dira que c'est une mauvaise conception, ne le faites pas, etc. Cependant, il est parfois plus facile à dire qu'à faire et déplacer l'implémentation dans un code commun séparé n'est pas souhaitable. Dans de tels cas, au lieu d'appeler directement l'autre package, émettez un événement à partir d'un package et gérez-le dans l'autre. De cette façon, vous n'avez pas besoin de faire de l'autre composant une dépendance dans le premier composant.
Si vous souhaitez toujours conserver l'implémentation dans des packages séparés, vous pouvez également dériver vos interfaces de formulaire de classes logiques et les définir dans un package distinct. Cela fonctionne si vous avez un moyen d'instancier l'implémentation, par exemple via l'injection de dépendances ou d'autres moyens.