Dependencias cíclicas

Question

Considere una aplicación normal de pedidos de clientes basada en el patrón MVC utilizando WinForms.La parte de vista ha crecido demasiado (más de 4000 archivos) y es necesario dividirla en partes más pequeñas.

---

Para este ejemplo vamos a utilizar 3 proyectos para la parte de vista:

• Principal - tiene dependencias de los otros 2 proyectos.Crea instancias de los formularios con las listas.
• Clientes - tiene 2 formularios: lista de clientes y detalles del cliente.
• Pedidos - tiene 2 formularios: lista de pedidos y detalles del pedido.

---

En el formulario de detalles del cliente también hay una lista de pedidos para ese cliente.La lista se recibe del OrdersController por lo que no hay problema para obtenerla.Cuando el usuario selecciona un pedido, la lista obtendrá su guía y la pasará como referencia al formulario Detalles del pedido.

Esto significaría que necesitamos tener una referencia al Proyecto de Pedidos en el Proyecto de Clientes. (1)

Pero también en el formulario de detalles del pedido hay un enlace al cliente que realizó ese pedido.Al hacer clic, debería abrir el formulario de Detalles del cliente.

Esto significaría que necesitamos tener una referencia al Proyecto Clientes en el Proyecto Pedidos. (2)

A partir de (1) y (2) tendremos dependencias cíclicas entre los proyectos de Pedidos y Clientes.

---

¿Cómo puede esto ser evitado? ¿Algún tipo de arquitectura de complemento?El proyecto ya está desarrollado y la mejor solución implicaría el menor cambio de código posible.

Answer 1

Cambie al menos uno de los tipos a una interfaz.

Por ejemplo, tenga una interfaz ICustomer y un tipo de Cliente que implemente esta interfaz.Ahora agregue ICustomer al proyecto de pedidos y desde el proyecto de clientes establezca una referencia al proyecto de pedidos para que pueda implementar la interfaz.El tipo de Orden ahora puede funcionar con el tipo ICustomer sin conocer la implementación real.

Y para una mejor solución :-) Cree una interfaz Icustomer y una interfaz iorder y agréguelos a un tercer proyecto de biblioteca.Y haga referencia a este proyecto desde los otros dos y solo trabaje con las interfaces, nunca con la implementación.

Answer 2

Si están tan estrechamente unidos tal vez no deberían dividirse.

Answer 3

Extraiga las interfaces y colóquelas en un ensamblaje separado.Como estás usando la arquitectura MVC, no debería ser difícil.Eche un vistazo al bloque de aplicaciones de interfaz de usuario compuesta de Microsoft para ver ejemplos y buenas prácticas.

Answer 4

Creo que tu principal problema no es la arquitectura de tu aplicación.Es necesario comprender los límites y cómo dividir la funcionalidad entre ellos.La división como la tuya es bastante artificial, intentas dividir la aplicación en función de los objetos del dominio.Intente utilizar roles de usuario o temas funcionales para eso y el problema podría desaparecer.

Desde el punto de vista técnico, no entiendo por qué sus puntos de vista deberían ser conscientes de la existencia del otro; eso me suena un poco extraño.No va a dividir sus datos y su lógica de negocios y, al final del día, un GUID es solo un pinchazo que puede transmitir fácilmente utilizando diferentes métodos.