Arquitectura para aplicaciones WinForms?

Question

Hace unas semanas comencé un proyecto de WinForms y como realmente no sabía qué funciones quería, las agregué en el camino. Esto ahora causó un lío horrible donde MainForm es una gran bola de barro y donde, por ejemplo, algunos elementos importantes de la IU desencadenan cambios de estado importantes hasta el punto que tengo que llamar Evento OnChange de un control para cambiar algún estado en la base de datos .

En resumen: acabo de comenzar un nuevo proyecto en el que deseo adoptar un mejor enfoque. Simplemente no sé cuál sería el "bueno". En ASP.net MVC, encontré que el patrón de MVVM es realmente útil, pero en el escritorio, MVVM parece ser solo para WPF, no para WinForms.

El otro enfoque es una arquitectura de tres niveles: tengo mi clase de base de datos que actualmente habla directamente con la interfaz de usuario. Ahora creo una nueva clase estática ("ApplicationState") que habla con la base de datos y dispara eventos para decirle a la interfaz de usuario "¡Oye, algo ha cambiado!". La interfaz de usuario manipularía el estado que luego manejará la persistencia de la base de datos y volverá a generar eventos si la interfaz de usuario necesita actualización. El punto aquí es que la clase ApplicationState nunca modifica la interfaz de usuario directamente, sino que la interfaz de usuario se suscribe a eventos. Que parece como una forma limpia/"MVC-y" de hacerlo, pero tal vez estoy pasando por alto algo aquí?

Básicamente, mi objetivo final sería tener la UI completamente independiente de la capa de la base de datos solo para asegurarme de no volver a conectar la lógica de negocios a la IU.

Answer 1

No tire la toalla sobre MVVM; también es válida para WinForms. Básicamente, si utiliza el enlace de datos, debe tomar una decisión sobre a qué se vincularán sus objetos. A menudo, especialmente para una IU más compleja, no desea vincularse directamente con los objetos de su dominio, desea crear clases especializadas (a veces envoltorios) a los que su UI pueda vincular, que brinden todo lo que la vista necesita (la esencia de MVVM) y la técnica funciona igual de bien con Winforms.

Una buena serie sobre el enfoque WinForms Modelo-Vista-Presentador se puede encontrar en

The Build Your Own CAB Series Table of Contents

Answer 2

Lo que siempre iría por (primera) es tener una aplicación en capas

• capa de presentación (SOLO interfaz de usuario y la lógica de enlace de datos)
• interfaz de capa a la capa de negocio (la definición de los contratos para el acceso a la BL)
• implementación de la capa de negocio (la lógica real, validación de datos, etc ...)
• interfaz de capa a la capa de acceso a datos (definición de los contratos para el acceso a la DAL)
• Implementación de la capa de acceso a los datos

Esto organiza su aplicación extremadamente bien. Entonces buscaría algún tipo de enfoque MVC. No desarrollé tanto con WinForms, más con Asp.net y algunos clientes de Java Desktop (donde utilicé MVC). WinForms trabaja más con el enfoque de enlace de datos .Net (DataSource, DataMember, ...). Deberías ir por ese enfoque en lugar de tratar de forzar algo diferente. Descubrí que no encaja tan bien.

Lo que siempre es útil es diseñar nuestra lógica de IU en diferentes controles (como UserControls en Asp.net). Esto facilita la reutilización.

Answer 3

Simplemente comience a escribir pruebas unitarias para todo lo que pueda pensar. Como algunas piezas se mostrarán difíciles de probar por unidad debido al acoplamiento ajustado a las WinForms, sepárelas. Limpiar. Wash. Repetir.

Answer 4

Nuestra regla de oro es a inclinarse hacia MVC para la mayoría de sitios web, debido a la naturaleza sin estado de la web. A menos que esté tratando de proporcionar una experiencia web muy rica y traer Silverlight, entonces debe ir con MVVM. XAML va de la mano con MVVM y también puede ser su opción de cliente inteligente (o un buen patrón de MVCP).

True MVC es casi imposible de mantener en cualquier otra circunstancia debido a que los controladores deben manejar todas las entradas. La mayoría de la arquitectura no web tiene controles que proporcionarán esto para usted. De hecho, la mayoría dice que ASP.NET MVC es un MVC híbrido de todos modos, pero es muy bueno en mi experiencia.

Answer 5

La documentación de NDepend viene con algunas publicaciones en el blog en línea muy interesantes y avanzadas, artículos y libros blancos sobre la arquitectura del código .NET.

Advices on partitioning code through .NET assemblies

Control Components Dependencies to gain Clean Architecture

Re-factoring, Re-Structuring and the cost of Levelizing

Evolutionary Design and Acyclic componentization

Layering, the Level metric and the Discourse of Method

Fighting Fabricated Complexity

Además, si desea comprobar continuamente que su código de interfaz de usuario es independiente de su código base de datos, se puede escribir fácilmente algunas reglas código de lenguaje de consulta que serán verificados en vivo en el tiempo de desarrollo en Visual Studio:

Keep your code structure clean

Answer 6

Nido framework es bueno. Sin embargo, es solo para su arquitectura de back-end. Le proporcionará un back-end sólido, flexible y simple con t4template. Demuestra tener un muy buen patrón arquitectónico. Además se puede conectar no sólo con WinForm pero con cualquier otro front-end (MVC ASP.NET etc) también ..

Por otra parte también es bueno RocketFramework

Link1: http://rocketframework.codeplex.com Link2: http://nidoframework.codeplex.com