net - unity ioc c#
Dependencias cíclicas (4)
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 debe dividirse en partes más pequeñas.
Para este ejemplo, vamos a usar 3 proyectos para la parte de vista:
- Main - tiene dependencias con los otros 2 proyectos. Instancia 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 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)
Desde (1) y (2) tendremos dependencias cíclicas entre los proyectos Pedidos y Clientes.
¿Cómo puede esto ser evitado? ¿Algún tipo de arquitectura plug-in? El proyecto ya está desarrollado y la mejor solución implicará el menor cambio de código posible.
Cambie al menos uno de los tipos a una interfaz.
Por ejemplo, tiene 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.
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. Trate de 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é tus puntos de vista deberían 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.
Extraiga las interfaces y colóquelas en un ensamblaje 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.
Si están tan estrechamente unidos, quizás no deberían dividirse.