Dependencias cíclicas

Question

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

---

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

• principal - tiene dependencias a los otros 2 proyectos. Instancia los formularios con las listas.
• Clientes - tiene 2 formas - lista de clientes y detalles del cliente.
• Pedidos - tiene 2 formas - lista de pedidos y detalles del pedido.

---

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

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

Pero también en el formulario de detalles de la orden hay un enlace al cliente que hizo ese pedido. Cuando se hace clic, debe abrir el formulario Detalles del cliente.

Esto significa que necesitamos tener una referencia al proyecto de clientes en el proyecto de pedidos.(2)

A partir de (1) y (2) que tendremos dependencias cíclicas entre las órdenes y los proyectos de los clientes.

---

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

Answer 1

Cambie al menos uno de los tipos a una interfaz.

Por ejemplo, tienen una interfaz ICustomer y un tipo de Cliente que implementa esta interfaz. Ahora agregue el ICustomer al proyecto de órdenes y desde el proyecto de clientes establezca una referencia al proyecto Orders para que pueda implementar la interfaz. El tipo de orden ahora puede funcionar en contra del tipo de cliente IC sin conocer la implementación real.

Y para una mejor solución :-) Cree un 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 quizás no deberían dividirse.

Answer 3

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

Answer 4

Creo que su problema principal no es la arquitectura de su aplicación. Debe comprender los límites y cómo dividir la funcionalidad entre ellos. La división como la tuya es bastante artificial, tratas de dividir la aplicación en función de los objetos del dominio. Intente usar 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 deben ser conscientes de la existencia de los demás, eso me suena un poco extraño. No dividirá sus datos y la lógica de su negocio y, al final del día, un GUID es simplemente un aguijón con el que podría pasar fácilmente utilizando diferentes métodos.