2009-10-26 15 views
12

Para implementar la GUI de la aplicación, me gustaría tener toda la lógica para pasar de una forma a otra centralizada. Este administrador de GUI se comportará como una máquina de estado finito. Aunque creo que he visto este tipo de implementación en algún lugar, no puedo encontrar un patrón de diseño que coincida con este tipo de solución.GUI como máquina de estados finitos

Una forma será así:

public class Login : Form 
{ 
    ... 

    private void EnterButton_Click() 
    { 
     ... 

     string user = loginTextBox.Text; 
     string password = passwordTextBox.Text; 
     bool isValid = SecurityManager.CheckUserLogin(user,password); 

     GUIManager.FormEnd(FormLogin,new LoginData(user, pass, isValid)); 
    } 

    ... 
} 

Y el gestor de interfaz gráfica de usuario va a hacer algo como esto:

public class GUIManager 
{ 
    ... 

    public void FormEnd(FormType type, FormData data) 
    { 
     switch (type) 
     { 
      ... 
      case FormLogin: 
       LoginData ld = (LoginData)data; 
       if (ld.Valid) 
       { 
        m_loginForm.Hide(); 
        m_mainForm.Show(); 
       } 
      ... 
     } 
    } 

    ... 
} 

Llegados a este punto tengo las siguientes preguntas: ¿existe un patrón el desing que formaliza esta idea? Si existe, ¿lo soporta .NET de alguna manera? Si no lo hay, ¿suena como una buena idea de implementación? ¡Gracias!

+0

+1 FSM para GUI es una muy buena idea! Tal vez podrías crear una DSL basada en XML para este propósito ... – ATorras

+0

En realidad, es una buena idea, y estoy cansado de navegar por el interminable mar de Microsoft infoclutter. Un montón de publicidad publicitaria en el enlace de Travis. Pero cuando leo los detalles, no veo ningún gran concepto. Solo la misma vieja basura. Te sugiero que sigas tu idea y trates de mantenerla impulsada por los datos. Después de todo, así es como se ven la mayoría de las máquinas de estado. –

Respuesta

4

¡Es una gran idea! Tan grande, de hecho, que se ha hecho antes y es probablemente el patrón más común utilizado en el desarrollo de aplicaciones extensibles (piense en IDEs como Visual Studio, Eclipse y similares).

Un ejemplo, SCSF (which leverages CAB), del Grupo de patrones y prácticas de MS, utiliza este patrón listo para usar para construir aplicaciones compuestas conectables y extensibles tanto en WinForms como en WPF. El patrón real que utiliza implica la construcción de máquinas de estado jerárquicas llamadas WorkItems que controlan los usos y fluyen a través de la aplicación. Miraría cómo los chicos de Patterns and Practices lo hicieron antes de implementarlo como mi propia creación. Lo he usado en muchas ocasiones y merece la pena.

+0

Eso suena genial. Estaba pidiendo específicamente este tipo de soporte en .NET. ¡Muchas gracias! – yeyeyerman

6

El State design pattern describe cómo implementar una máquina de estados finitos.

Hay muchos patrones de diseño ligeramente diferentes para controlar las pantallas en la interfaz de usuario, pero creo que el Application Controller design pattern se ajusta a lo que está tratando de hacer.

+0

El controlador de aplicaciones describe un control centralizado para toda la aplicación y es realmente útil. Pero aún no habla sobre el FSM. – yeyeyerman

1

En el mundo Java se puede pensar en una Struts o aplicación JSF como una MEF (este evento en esta página/Estado nos lleva a esa página/estado.

Al modelar los flujos en el basado en la web, un tradicional UI Encontré el uso de FSM como una herramienta de análisis extremadamente útil. Puede capturar muy rápidamente la esencia del comportamiento de la aplicación. Hubo una correspondencia casi uno a uno entre página y estado. modelo de estado y modelos de datos asociados.

Ahora tenemos UI más ricas explotando AJAX la correspondencia entre una p los estados de plicatura y "páginas" son menos obvios. Sin embargo, todavía puede razonar sobre el comportamiento de la aplicación: aquí el usuario está haciendo este, cuando hayan terminado pueden realizar acciones X o Y y luego pueden hacer que. Así que los estados, eventos y transiciones aún existen, es solo que su representación es un poco más "virtual".

+0

Estoy de acuerdo.Estaba buscando un tipo de marco de Struts para desarrollar la GUI, por lo que puedes desacoplar la lógica del flujo de trabajo de la lógica de los diálogos. Gracias por tu punto. – yeyeyerman

Cuestiones relacionadas