Comencé un proyecto de WinForms hace unas semanas y, como no sabía realmente qué funciones quería, las agregué en el camino. Esto ahora causó un desastre horrible en el que mi MainForm es una gran bola de barro y donde, por ejemplo, algunos elementos importantes de la interfaz de usuario desencadenan algunos cambios de estado al punto que debo llamar al 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 quiero tener un mejor enfoque. Simplemente no sé cuál sería el "bueno". En ASP.net MVC, encontré el patrón MVVM realmente útil, pero en el escritorio, MVVM parece estar destinado 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 cambió!". La UI manipularía el estado que luego manejará la persistencia de la base de datos y volverá a generar eventos si la UI necesita actualizarse. El punto aquí es que la clase ApplicationState nunca modifica la IU directamente, sino que la UI se suscribe a Eventos. Esemiradas como una forma limpia / "MVC-y" de hacerlo, pero ¿quizás 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 que no conecto la lógica de negocios a la UI nuevamente.