Des modules sur la même couche dans l'architecture en couches

Question

En théorie de l'architecture en couches, vous pouvez avoir plusieurs modules sur la même couche. Ce module peut référence croisée à l'autre? Est-il possible sur le plan technique, par exemple. en utilisant .NET?

Answer 1

Il est certainement possible de le faire, juste faire attention de ne pas introduire des dépendances cycliques entre les modules. En général, les modules à une couche donnée ne doit dépendre d'autres modules de la même couche ou des couches en dessous. Les modules ne doivent pas être au courant des couches au-dessus.

Si vous voulez en faire encore plus stricte, vous pouvez également limiter les dépendances à d'autres modules de la même ou d'autres couches immédiatement sous l'actuel.

Garder l'interface exposée à un minimum, par exemple, exposer seulement un ensemble de base d'interfaces publiques, des objets de valeur et des exceptions est toujours une bonne idée. Vous pouvez utiliser pour limiter la visibilité des composants internes du module de contrôle d'accès de langue caractéristiques (c.-à-privé / paquet / publics) de se répandre dans d'autres couches.

Answer 2

Techniquement, vous pouvez recouper dans toutes les directions que vous voulez dans .NET (il n'y a pas des limites techniques pour une DAL pour référencer un composant d'interface utilisateur, même si elle ne peut pas être une bonne idée). Je ne vois aucun problème avec le référencement des modules au sein de la même couche.

Mais nous devons regarder le mot « couche » un peu, car les couches sont disponibles en différentes formes et tailles. Souvent, lorsque nous utilisons le mot « couche » nous pensons que l'accès aux données couche ou couche de présentation, et nous permettent généralement des couches regarder vers le bas, mais pas upwars.

Dans chaque couche, les différents modules permettent également souvent eux-mêmes être disposés en couches, logiquement. La même règle vaut ici; un module peut regarder vers le bas, mais pas. Dans cet esprit, il se sent plutôt sûr de faire référence à des modules au sein de la même couche (externe).

Il suffit de ne pas avoir deux modules de référence entre eux, directement ou indirectement. Si vous trouvez que A et B à la fois besoin d'une fonctionnalité de l'autre (ce qui indique que A et B sont au même niveau), vous aurez probablement besoin de factoriser le code, l'introduction peut-être un nouveau module C, logiquement placé sous A et B que les deux d'entre eux peuvent utiliser.

Gardez également à l'esprit de garder les modules aussi détaché que possible; moins ils connaissent les uns les autres, mieux.

Answer 3

comme Pavel dit, soyez prudent avec vos dépendances cycliques. Si vous ne pouvez absolument pas vivre sans une dépendance cyclique (ce que vous appelez référence croisée), les classes doivent être non seulement de la même « couche », mais aussi le même ensemble.

Cela étant dit, il devrait y avoir aucune raison pour que les références croisées -. Non seulement devrait (comme pavel dit) modules ne dépendent que les couches en dessous d'eux, que d'une façon dépendance devrait exister dans tous les cas

Il y a quelques exceptions logiques à cette règle, par exemple dans quelque chose comme un modèle de domaine - un client aura un certain nombre de commandes, par exemple. Il pourrait être utile dans ce cas (en particulier avec ORM, etc) pour avoir une liste des commandes sur le client, et une référence au client de chaque commande. En termes d'unités de fonctionnalités comme les services, etc., il ne devrait y avoir une dépendance à sens unique.

Une façon de contourner ce problème est d'utiliser l'inversion de contrôle par Windsor, autofac, spring.net etc. Vous pouvez définir une interface dans un ensemble et un autre objet qui consomme une mise en œuvre concrète de cette interface. Une autre bibliothèque peut contenir la mise en œuvre réelle (ce qui signifie que doit faire référence à l'ensemble du premier ensemble). Dans ce cas, le conteneur IoC saisit la mise en œuvre.