Módulos de la misma capa en arquitectura en capas

Question

En la teoría de la arquitectura en capas puede tener varios módulos en la misma capa. Puede este módulo de referencia cruzada entre sí? Es decir es posible técnicamente, por ejemplo. utilizando .NET?

Answer 1

Sin duda, es posible hacerlo, pero tenga cuidado de no introducir dependencias cíclicas entre los módulos. En general, los módulos en una capa dada sólo deben depender de otros módulos de la misma capa o de las capas por debajo de ella. Los módulos no deben estar al tanto de las capas por encima de ellos.

Si quieres hacer esto aún más estricto, entonces usted puede también limitar las dependencias a otros módulos de la misma u otras capas inmediatamente por debajo de la actual.

Mantener la interfaz expuesta a un mínimo, por ejemplo, exponer solamente un conjunto básico de interfaces públicas, objetos de valor, y las excepciones es siempre una buena idea. Puede utilizar las funciones de control de acceso del lenguaje (es decir, / paquete / públicas privada) para limitar la visibilidad de los componentes internos del módulo que se derrame en otras capas.

Answer 2

Técnicamente se puede hacer una referencia cruzada en cualquier dirección que desee en .NET (no hay limitaciones técnicas para una DAL para hacer referencia a un componente de interfaz de usuario, aunque puede que no sea una buena idea). Veo ningún problema con referencia a módulos dentro de la misma capa.

Pero tenemos que mirar a la palabra "capa" un poco, ya que las capas vienen en diferentes formas y tamaños. A menudo, cuando utilizamos el término "capa" que pensamos de acceso a datos de capa o capa de presentación, y nos permiten típicamente capas de mirar hacia abajo, pero no upwars.

Dentro de cada capa, los diferentes módulos a menudo también se dejan dispuestas en capas, lógicamente. La misma regla se aplica aquí; un módulo puede mirar hacia abajo, pero no hacia arriba. Con esto en mente, se siente más seguro para hacer referencia a módulos dentro de la misma capa (exterior).

Eso sí, no tienen Referencia dos módulos entre sí, directa o indirectamente. Si usted encuentra que A y B necesita una funcionalidad entre sí (lo que indica que A y B están en el mismo nivel), es probable que necesite refactorizar el código, tal vez la introducción de un nuevo módulo C, lógicamente colocado por debajo de A y B que tanto de ellos se puede utilizar.

También hay que tener en cuenta para mantener los módulos como independiente como sea posible; cuanto menos saben el uno del otro, mejor.

Answer 3

como dijo Pavel, tener cuidado con sus dependencias cíclicas. Si usted no puede vivir sin una dependencia cíclica (lo que se llama una referencia cruzada), las clases deben ser no sólo de la misma 'capa', sino también el mismo conjunto.

Una vez dicho esto, no debería haber ninguna razón para referencias cruzadas -. No sólo si (como dijo Pavel) sólo los módulos dependen de las capas por debajo de ellos, que en un solo sentido, la dependencia debe existir en todos los casos

Hay algunas excepciones a esta regla lógicas, por ejemplo, en algo así como un modelo de dominio - un cliente tendrá un número de pedidos, por ejemplo. Podría ser útil en ese caso (ESP con ORM etc.) para tener una lista de pedidos de los clientes, y una referencia para el cliente de cada pedido. En términos de unidades de funcionalidad como servicios, etc., no sólo debe ser una forma de dependencias.

Una forma de solucionar este problema es el uso de Inversión de Control a través de Windsor, autofac, spring.net etc. Se puede definir una interfaz en una asamblea y otro objeto que consume una aplicación concreta de esa interfaz. Otra biblioteca podría contener la implementación real (lo que significa que todo deberá hacer referencia a la primera asamblea). En este caso, el contenedor IoC agarra la aplicación.