¿Cómo debería estructurar una solución de formularios Win de datos?

Question

Estoy escribiendo una aplicación de Windows Forms que está creciendo y llegando a ser bastante extensa.

Inicialmente, pensé que un mejor proyecto sería un proyecto separado para componentes gráficos y uno para lógica comercial y otro para acceso a datos.

A medida que la aplicación aumenta, estoy empezando a pensar que un enfoque más modular sería más limpio ... p. un proyecto que contiene controles de usuario, lógica comercial y acceso a datos para cada 'categoría' de datos.

Por ejemplo ... Objetos DAL relacionados con Productos junto con los objetos comerciales asociados y controles de usuario en un solo proyecto. Esto debería terminar con una mayor cantidad de proyectos dentro de la solución, cada uno de ellos autónomo.

Esto puede, sin embargo, causar más complicaciones ya que los datos a menudo están vinculados (la tabla del producto está vinculada a la tabla del proveedor, tabla de pedidos y tabla de lista de partes, etc.). Por lo tanto, sería difícil abstraer completamente cada categoría.

Hay cientos de artículos de arquitectura de software en línea, pero no muchos que le ayuden a traducir esa arquitectura en soluciones, proyectos y códigos.

¿Alguien podría indicarme la dirección correcta?

Answer 1

Me gustaría mantener la interfaz de usuario, los datos y las capas de negocios en proyectos separados. Esto reduce esencialmente las posibilidades de acoplamiento ajustado, por ejemplo, la capa de datos utilizada directamente por el código UI, etc. Ahora, si desea dividir esto verticalmente, puede hacerlo así como, por ejemplo, los Productos tendrán tres proyectos UI, Negocio & Dal y pronto. Puede haber múltiples consideraciones aquí:

1. ¿Por qué se separa verticalmente? ¿Ve una posible reutilización independiente? Si no, entonces evita dividir.
2. Si debe dividir, puede elegir dividir decir solo capa de IU desde la perspectiva de gestión, ya que puede tener gran cantidad de código
3. O puede dividir todas las capas, pero a grano grueso. Por ejemplo, Productos y también sus hijos juntos.

Por lo que respecta a las referencias de categoría cruzada, no se pueden evitar, pero se deben hacer a través de un contrato bien documentado & diseñado. Por ejemplo, la IU de Pedidos puede llamar a Productos BL para obtener una lista de productos (tenga en cuenta que muchos otros componentes de UI utilizarán el mismo método para funciones similares).

Answer 2

VinayC está en ello, aquí hay algunos extras que aumentan su respuesta (demasiado difícil en un comentario).

• Resuma todos los accesos de datos detrás de las interfaces, de esa manera puede intercambiar diferentes dentro y fuera, y no tendrá tantas dependencias conectadas al resto de la aplicación.
• Cuando diseñe estas interfaces, podrá aplicar parte de su pensamiento "vertical". Ver: Interface Segregation Principle y Stable Abstractions Principle como inicio.
• Haría un ensamblaje (y proyecto) separado para cada capa, más un conjunto "común" para constantes, etc. Mantenga esto lo más libre de dependencias posible.
• Donde he usado este enfoque, algunas veces pongo mi POCO en una carpeta en el ensamble común para que puedan ser fácilmente reutilizados.Las interfaces que utilizo para separar BL y DAL las usan, y algunas veces las vuelvo a usar también entre otras capas.
• Considere el uso de atributos; pueden proporcionarle un punto de extensibilidad realmente útil.
• Coloque los controles de uso común en las bibliotecas de control para facilitar su reutilización.
• No intente separar partes de un modelo de dominio/modelo de datos (por ejemplo, orden y partes) que estén estrechamente vinculados entre sí en un sentido comercial.